Precisely, how does Everything handle hard links? I've read what I could find in the forums, but many posts are quite old.
I do use quite a few hard links in my workflow, so I'd appreciate an exact answer on this - or some help finding a reference that I missed.
Does it change its behavior if USN Journal is not used? It seems that renaming one affects updating?
Any chance we'll be able to do an Everything search that specifically seeks hard links?
Also, if applicable, where you are headed with this?
***
And how about symbolic links and junctions? Are symbolic links handled differently if they refer to a file versus a folder? Or hop volumes? USN Journal used or not?
My apologies if this information is available clearly elsewhere, and also for personally having more of a practical understanding of their use rather than an extremely precise understanding on a file system level.
My thanks in advance.
What is the Current Status of How E. Handles Hard Links?
Re: What is the Current Status of How E. Handles Hard Links?
Everything 1.3 only indexes the first instance of a hardlink.Precisely, how does Everything handle hard links?
Everything 1.4 indexes all long filename hardlinks from the MFT.
There are some limitations with Everything 1.4:
When a change is made to a hard link, the size, date modified, date created and attributes of only the first hard link instance is updated.
For example, if you have two hard-linked files:
a.txt and b.txt, if you modify a.txt, Everything will only receive an update notification for one of the files, which one depends on the first hard link entry in the MFT, so it is possible Everything will only update b.txt
This is a limitation with the USN Journal. The filename in a USN Change Journal record is generally the first hard link instance.
What I have on my TODO list is to use the FRN from the USN Change Journal record and lookup all the hard links, of course there's a minor performance hit in doing so.
To update all hard links you will need to force a rebuild from Tools -> Options -> Indexes -> Force rebuild.
Everything does not follow junctions automatically.
Junctions to NTFS volumes can be added manually.
Junctions to non-NTFS volumes are not supported, you will need to use folder indexing for these.
Folder indexing will follow junctions.
Currently they are treated the same, that is Everything does not follow the junction or symbolic link.And how about symbolic links and junctions?
You can setup Everything to follow either of these manually.
http://www.voidtools.com/support/everyt ... imitations
Re: What is the Current Status of How E. Handles Hard Links?
Thank you - very much - for taking the time to answer my question.
-
gggirlgeek
- Posts: 52
- Joined: Tue Dec 28, 2010 4:54 pm
Re: What is the Current Status of How E. Handles Hard Links?
This solution seems like a lot of work and is more difficult than simply scanning the folder locations in the "Folders" tab of Everything's Options. After this you untick the same Drive in the NTFS tab and you're good to go. All hardlinks and symlinks and junctions will show up.
For example: Scan drive C: into the Folders. Disable drive C: from NTFS options. Search for Notepad.exe. You'll see it's Hardlinks, and no duplicate listings.
Example 2: Create a symlink of S:\Test on C:\Test. With C:\ Folder still set to scan, search for "c:/test". You'll see the symlink.
Example 3: With the above settings search for Application Data. You'll see the Junctions for Application Data on the C: drive.
Just set C: drive to scan every 3 or 6 hours and your data should be close to current. (I actually keep a separate Everything instance for this purpose.)
For example: Scan drive C: into the Folders. Disable drive C: from NTFS options. Search for Notepad.exe. You'll see it's Hardlinks, and no duplicate listings.
Example 2: Create a symlink of S:\Test on C:\Test. With C:\ Folder still set to scan, search for "c:/test". You'll see the symlink.
Example 3: With the above settings search for Application Data. You'll see the Junctions for Application Data on the C: drive.
Just set C: drive to scan every 3 or 6 hours and your data should be close to current. (I actually keep a separate Everything instance for this purpose.)
-
gggirlgeek
- Posts: 52
- Joined: Tue Dec 28, 2010 4:54 pm
Re: What is the Current Status of How E. Handles Hard Links?
I wonder why the new indexing options don't pull up sym links like folder-scan does? I realize speed would be a problem but don't understand why since the new index is a data list too.
Re: What is the Current Status of How E. Handles Hard Links?
@void can probably explain this much better, but I will take a shot ...
Everything 1.4 could miss some hardlink updates as described above.
Everything 1.5 (currently available as alpha version) *does* track hard links.
Soft-links (symbolic links) is a different story Roughly speaking they are shortcuts to another folder or (less relevant here) file.
That folder could be on the same drive/volume, but also on a different volume, even network share.
Everything tracks the NTFS filesystem of a drive for it's information. That NTFS filesystem has no awareness of the content of the symbolic link if it maps to a different volume.
When you follow symbolic links, a single file will be shown in Everything results multiple times: one in the original location (S:\test\file.txt and one through following the symbolic link (C:\test\file.txt).
If I understood correctly, that is something void would like to a-void.
That being said ...
If you want to include symbolic links on a NTFS volume- let's say your C:-drive - you don't have to fall back to folder indexing that volume.
Instead, you can use a hybrid approach: Keep using NTFS indexing for your C:-drive and use folder indexing for your symlink folders.
For that, you cna add C:\test to Folder indexing and create a fitting update schedule for it.
Disadvantage is that those files will be shown twice, as mentioned before and they might not be 100% up-to-date in the database, depending on your update schedule.
You can list all your symbolic links on your C:-drive by searching for
(For quick results, enable Index attributes first (Menu:Tools > Options > Indexes))
EDIT:
Now I think of it .. Everything follows volume mount points (where you mount a drive as a folder instead of/next to a drive letter).
Did not check it, but I thought that was a symbolic link too. Maybe a special case?
Everything 1.4 could miss some hardlink updates as described above.
Everything 1.5 (currently available as alpha version) *does* track hard links.
Soft-links (symbolic links) is a different story Roughly speaking they are shortcuts to another folder or (less relevant here) file.
That folder could be on the same drive/volume, but also on a different volume, even network share.
Everything tracks the NTFS filesystem of a drive for it's information. That NTFS filesystem has no awareness of the content of the symbolic link if it maps to a different volume.
When you follow symbolic links, a single file will be shown in Everything results multiple times: one in the original location (S:\test\file.txt and one through following the symbolic link (C:\test\file.txt).
If I understood correctly, that is something void would like to a-void.
That being said ...
If you want to include symbolic links on a NTFS volume- let's say your C:-drive - you don't have to fall back to folder indexing that volume.
Instead, you can use a hybrid approach: Keep using NTFS indexing for your C:-drive and use folder indexing for your symlink folders.
For that, you cna add C:\test to Folder indexing and create a fitting update schedule for it.
Disadvantage is that those files will be shown twice, as mentioned before and they might not be 100% up-to-date in the database, depending on your update schedule.
You can list all your symbolic links on your C:-drive by searching for
c:\ attrib:L(For quick results, enable Index attributes first (Menu:Tools > Options > Indexes))
EDIT:
Now I think of it .. Everything follows volume mount points (where you mount a drive as a folder instead of/next to a drive letter).
Did not check it, but I thought that was a symbolic link too. Maybe a special case?
Re: What is the Current Status of How E. Handles Hard Links?
Everything does not follow folder symbolic links.
I will consider an option to follow folder symbolic links.
However, do not expect this to be efficient.
Each folder symbolic link needs to be treated as a its own volume.
There's a lot of standard Windows folders that are folder symbolic link, for example:
C:\Documents and Settings => C:\Users
C:\Users\All Users => C:\ProgramData
which leads to:
C:\Documents and Settings\All Users => C:\ProgramData
Indexing these folder junctions might bloat your index.
For now, you can add a folder junction as a volume.
How many folder junctions are you looking at indexing?
There's a reparse point property in Everything 1.5 to quickly find folder junctions.
Everything 1.5 tracks new and renamed hard links.
Everything 1.5 does not track deleted hard links.
I will consider an option to follow folder symbolic links.
However, do not expect this to be efficient.
Each folder symbolic link needs to be treated as a its own volume.
There's a lot of standard Windows folders that are folder symbolic link, for example:
C:\Documents and Settings => C:\Users
C:\Users\All Users => C:\ProgramData
which leads to:
C:\Documents and Settings\All Users => C:\ProgramData
Indexing these folder junctions might bloat your index.
For now, you can add a folder junction as a volume.
How many folder junctions are you looking at indexing?
There's a reparse point property in Everything 1.5 to quickly find folder junctions.
Everything 1.5 tracks new and renamed hard links.
Everything 1.5 does not track deleted hard links.