Straighten up the GFileType vs symlinks on Windows situation

On Windows NTFS symlinks are implemented as reparse points,
which are special kinds of files *or directories*. A directory
symlink should link to a directory. A file symlink should link
to a file. Mismatching (such as a file symlink pointing to a
directory) produces symlinks that simply do not function.

Therefore GFileType file vs directory vs symlink distinction is
too simplistic to correctly represent a NTFS filesystem object type.

Since we can't turn back time and choose a better way of representing
file types, make GFileType reflect the file vs directory type on
Windows, meaning that all FS objects are either files or
directories (or shortcuts, which are also files), but never symlinks.

A test for symlinkiness will have to be made via GFileInfo - it
tracks symlinkiness separately from file/directory/whatever.
This commit is contained in:
Руслан Ижбулатов
2018-08-24 08:57:20 +00:00
parent c2a5537845
commit 19608e36d2
4 changed files with 14 additions and 4 deletions

View File

@@ -76,6 +76,7 @@ typedef struct _GFileInfoClass GFileInfoClass;
* A key in the "standard" namespace for checking if the file is a symlink.
* Typically the actual type is something else, if we followed the symlink
* to get the type.
* On Windows NTFS mountpoints are considered to be symlinks as well.
* Corresponding #GFileAttributeType is %G_FILE_ATTRIBUTE_TYPE_BOOLEAN.
**/
#define G_FILE_ATTRIBUTE_STANDARD_IS_SYMLINK "standard::is-symlink" /* boolean */