Re: [ntfs-3g-devel] Improving symbolic link interoperability with Windows
Thanks for the explanation (I suspected it wouldn't be easy). Considering the quirks of using Windows native symlinks (such as different symlink types for files and directories) I understand your conclusion that it costs more than it is worth. Zoltan Jean-Pierre Andre wrote: Zoltan Kelemen wrote: Hello, When symbolic links are created on an NTFS volume on a Linux system, they are currently mapped by NTFS-3G to so-called Interix-type files. If the volume is mounted on Windows, these links can only be natively resolved by installing the (deprecated) UAS services. Cygwin has limited support for these links (they can be read but not created) and the link types created by default by Cygwin can not be resolved by NTFS-3G. It would therefore be nice if NTFS-3G had an option to create Windows native symbolic links if supported by the NTFS version (from Vista and up). This would improve interoperability both with native Windows- and Cygwin apps using a single, coherent link format. The major problem with this is that Windows and Linux have a different way of designating a partition. There is no easy way to tell whether you have to translate a target designated as /foo/bar into D:\bar or F:\bar or whatever drive letter is used for designating the target partition. A way for translating from Windows drive letters to Linux mount points has been defined for resolving Windows-type symlinks. Nobody uses that because it is too complex. (http://jp-andre.pagesperso-orange.fr/junctions.html) Moreover this is defeated for pluggable devices which get a drive letter depending on the socket used and what has been plugged before. So, I consider defining symlinks to absolute targets as unreasonable. As Cygwin runs on Windows, it has a better knowledge of the Windows configuration than ntfs-3g can have, so its way of doing symlinks does not apply to Linux. Now, relative symlinks whose target is on the same partition need not use drive letters or mount points, so they are more reachable. There is still a hurdle, as on Windows, symlinks to directories are different from symlinks to files, so the target has to exist for creating a symlink according to the target. You might be interested in "winsln" which is one of the tools downloadable from http://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g.html#download for creating relative symlinks whose target lies on the same partition as the symlink. This is also a way to get a grisp on the limitations. Considering the differences between Windows symlinks and Linux ones, using the Windows way on Linux will probably create more problems than benefits. Jean-Pierre Regards, Zoltan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
Re: [ntfs-3g-devel] Improving symbolic link interoperability with Windows
Hi, Zoltan Kelemen wrote: Hello, When symbolic links are created on an NTFS volume on a Linux system, they are currently mapped by NTFS-3G to so-called Interix-type files. If the volume is mounted on Windows, these links can only be natively resolved by installing the (deprecated) UAS services. Cygwin has limited support for these links (they can be read but not created) and the link types created by default by Cygwin can not be resolved by NTFS-3G. It would therefore be nice if NTFS-3G had an option to create Windows native symbolic links if supported by the NTFS version (from Vista and up). This would improve interoperability both with native Windows- and Cygwin apps using a single, coherent link format. The major problem with this is that Windows and Linux have a different way of designating a partition. There is no easy way to tell whether you have to translate a target designated as /foo/bar into D:\bar or F:\bar or whatever drive letter is used for designating the target partition. A way for translating from Windows drive letters to Linux mount points has been defined for resolving Windows-type symlinks. Nobody uses that because it is too complex. (http://jp-andre.pagesperso-orange.fr/junctions.html) Moreover this is defeated for pluggable devices which get a drive letter depending on the socket used and what has been plugged before. So, I consider defining symlinks to absolute targets as unreasonable. As Cygwin runs on Windows, it has a better knowledge of the Windows configuration than ntfs-3g can have, so its way of doing symlinks does not apply to Linux. Now, relative symlinks whose target is on the same partition need not use drive letters or mount points, so they are more reachable. There is still a hurdle, as on Windows, symlinks to directories are different from symlinks to files, so the target has to exist for creating a symlink according to the target. You might be interested in "winsln" which is one of the tools downloadable from http://jp-andre.pagesperso-orange.fr/advanced-ntfs-3g.html#download for creating relative symlinks whose target lies on the same partition as the symlink. This is also a way to get a grisp on the limitations. Considering the differences between Windows symlinks and Linux ones, using the Windows way on Linux will probably create more problems than benefits. Jean-Pierre Regards, Zoltan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
[ntfs-3g-devel] Improving symbolic link interoperability with Windows
Hello, When symbolic links are created on an NTFS volume on a Linux system, they are currently mapped by NTFS-3G to so-called Interix-type files. If the volume is mounted on Windows, these links can only be natively resolved by installing the (deprecated) UAS services. Cygwin has limited support for these links (they can be read but not created) and the link types created by default by Cygwin can not be resolved by NTFS-3G. It would therefore be nice if NTFS-3G had an option to create Windows native symbolic links if supported by the NTFS version (from Vista and up). This would improve interoperability both with native Windows- and Cygwin apps using a single, coherent link format. Regards, Zoltan -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
