Hello, Git does not have "configure" script, so I used 2017.3.23 from Tuxera website to apply the patch. Running "stat" command for files worked as expected; I got inconsistent results with directories, but I believe that this functionality is not needed in ntfs-3g - Microsoft states that hard links for directories are prohibited:
(...) For example, in a system where C: and D: are local drives and Z: is a network drive mapped to \\fred\share, the following references are permitted as a hard link: (...) The following are not: C:\dira linked to C:\dirb (...) https://docs.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions Directories can be referenced, in terms of Microsoft, by "junctions" and "symbolic links" - those worked well in my testings, except for entries created by Windows 10 like "Windows\notepad.exe" where "stat" command has "unsupported reparse point" in its output. Alexander Shchadilov вт, 28 июл. 2020 г. в 10:09, Jean-Pierre André <jean-pierre.an...@wanadoo.fr>: > > Hi, > > Attached is an updated patch for computing a Posix compliant > count of links, including for directories. > > The option has been renamed posix_nlink. > > Please test and report. > > Jean-Pierre > > Jean-Pierre André wrote on 7/27/20 10:49 AM: > > Hi, > > > > Attached is a proposed patch for computing the hard links counts > > whenever it is required, instead of relying on the value stored on disk. > > This obviously causes some extra delay when listing a crowded > > directory such as \Windows\System32. > > > > This feature is activated by setting the mount option "hard_links". > > Please test and report. > > > > Note : this does not apply to directories. Counting the number > > of subdirectories is much more time consuming. > > > > Jean-Pierre > > > > Alexander Shchadilov wrote on 7/26/20 10:17 PM: > >> Hello, > >> It seems that a counter in an MFT entry that is often referred to as a > >> "hard link counter" (offset 0x12 - 0x13) is increased by one when > >> Windows adds an 8.3 alias for a file name. > >> Description of short names in Windows docs: > >> > >> "When you create a long file name, Windows may also create a short 8.3 > >> form of the name, called the 8.3 alias or short name, and store it on > >> disk also." > >> > >> ntfs-3g should differentiate hard links and short names, even if they > >> are stored on disk in a similar way, and calculate an accurate number > >> of hard links. I can not provide an established definition of a hard > >> link from some Linux-related standard, but the following command in > >> Windows 10 will not show a 8.3 name in its output: > >> fsutil hardlink list <filename> > >> >From fsutil documentation: > >> > >> A hard link is a directory entry for a file. Every file can be > >> considered to have at least one hard link. > >> On NTFS volumes, each file can have multiple hard links, so a single > >> file can appear in many directories (or even in the same directory > >> with different names). > >> > >> Considering that this definition is provided by Microsoft, the company > >> that developed NTFS, and 8.3 names do not make a file "appear in the > >> same directory with different names" when viewed by File Explorer in > >> Windows, I think it is safe to tell that a short alias should be > >> excluded from a number of hard links. > >> This issue was discovered in the discussion of QDirStat bug (issue #88 > >> on Github). > >> > >> Best wishes, > >> Alexander Shchadilov > >> > >> > >> > > > _______________________________________________ ntfs-3g-devel mailing list ntfs-3g-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
