[FEATURE] g_file_make_symbolic_link() is not W32-friendly enough
Just found this function, and at first i thought "wow, this is awesome!". But the interface is, sadly, a copy of symlink()
with a GError
and a cancellable object thrown in.
To easily implement this on Windows this function needs an extra argument - the type of the link to create, since on Windows NTFS symlinks are either files or directories, but not both at the same time, and this is set when the link is created (i haven't tried to create a symlink and then edit its filesystem entry to change its type after the fact; not sure whether it would work, and whether it is worth digging in that direction at all). Wrongly-typed symlinks won't function (or, rather, function just as good as dangling symlinks do).
It's impossible to fix this for symlink()
and other POSIX functions, since their interface is frozen (that's what POSIX compatibility means; one of the reasons why Cygwin has so much problems with symlinks), but GLib isn't POSIX, it has flexibility (and a bit of a reach too).
So, questions:
- Is it feasible to change the signature of this API (or will it have to wait until glib-3.0, which will probably never happen)?
- If not, is it feasible to add a new API with the extra argument (and, hopefully, document that this new API should be preferred)?
- If yes, what would that argument be? I'm thinking a flag field, with something like
G_SYMLINK_AUTO
being the default (0
) andG_SYMLINK_FILE
(1
) andG_SYMLINK_DIRECTORY
(2
) being possible (and mutually-exclusive) options.