On 06/02/2015 20:19, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Dave Thompson >> Sent: Friday, February 06, 2015 12:04 >> >> * Windows beginning AIR XP or maybe NT does support links on NTFS, >> but they're not easy to use and not well known, and I think I saw a recent >> bug report that they don't even work for OpenSSL, at least sometimes. > In modern versions of Windows, NTFS supports three sorts of link-like objects: file symbolic links, directory symbolic links, and junctions, all of which are types of reparse points. Older versions of NTFS only support junctions. These can be created with the mklink command. Prior to Vista, there was no command in the base OS for this purpose, and you needed something like linkd from the Windows Server Resource Kit to manipulate links. Actually, there is a 4th and 5th form of NTFS native symbolic links: "POSIX" subsystem symbolic links, which have all the expected semantics but may not work with Win32 programs such as OpenSSL; and DFS junctions which have special semantics for the SMB/CIFS file sharing protocol. > I just did a bit of testing with openssl.exe from OpenSSL 1.0.1k. It appears to work correctly with all three. > > Windows also supports "shortcuts", but those are a Windows Explorer artifact. They're just files that have a particular extension and particular sort of contents. OpenSSL doesn't support them, but then neither do most programs. Shortcuts were invented for Windows 95 to overcome some of the limitations of the FAT32 filesystem. They're rubbish. Actually, shortcuts are really desktop/start menu entries, which store a command line, startup directory, menu icon and launch options. They work like the ".desktop" files in modern Linux desktop environments and should never have been confused with symbolic links. They were created as a more flexible replacement for the Windows 3.x program manager icon group files. > And Cygwin provides both hard and symbolic UNIX-style links for NTFS. Hard links can only be to files. I'm not sure how Cygwin implements them, but they seem to work fine with OpenSSL. All versions of NTFS support hard links natively, though there is no command in the base OS to create them, and prior to Windows 2000, they could only be created via an undocumented API and/or by using the "POSIX" subsystem (which did include a working ln command though). When you run chkdsk (fsck) on an NTFS file system, you will see inodes referred to as "Files" in the "Master File Table" and directories as "Indexes". > Cygwin supports multiple implementations of symbolic links; see https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks. Default symbolic links are ordinary files recognized by the Cygwin library as special, so they aren't handled by (non-Cygwin) OpenSSL. Shortcut-style symlinks are shortcuts, so per above they do not work. Native symlinks are Windows symlinks and should work fine with OpenSSL. The native implementation can be selected by setting the CYGWIN environment variable appropriately, so (contrary to recent messages on the list) there's no reason to rewrite c_rehash for use on Windows. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
