Mitch Capper wrote: > It is true that Windows historically hasn't had great symbolic and hard > linking api's / compatibility but the largest barriers were largely removed > back in 2016 with all in-support versions of Windows having full symbolic > link support without any special developer options/admin requirements. For > the most part Windows support mirrors that of *nix platforms now with 3 key > variances: > > 1) Directory symbolic links are distinct from file symbolic links. While I > could have the API cover this up as it can be important I try to return > what seemed the most true representation. S_DIR does return true for > symbolic directory links and the new S_HARDDIR returns true if the > directory is not a symbolic link. This seemed most intuitive in most > situations. The primary exception is code that switches on the file system > entry and checks S_DIR before S_SYMLINK may need those things reversed. > > 2) While Windows supports normal volume symlinks like c:/some/dir it also > supports using the volume GUID in place of the drive letter. This however > is not a format that can be seamlessly handled by most applications not > expecting it so is not returned by default. > > 3) Windows still has "directory junctions" left over which are similar to > directory symbolic links. They differ mostly in terms of resolution in > remote file share situations. These I return information on as if they are > standard directory symlinks and do not provide a way to create (as the > concept doesn't really exist in *nix). This is similar to how Windows > native renders directory junctions / directory sym links in most situations.
Thanks for these explanations. If I understand it correctly, S_ISHARDDIR(m) is equivalent to S_ISDIR(m) && ! S_ISLNK(m). Right? File names with a GUID in place of the drive letter are IMO not something that should be presented to the user. So, I agree with you that Gnulib functions should not return such file names by default. Bruno
