Monitor Changes bug when Rename CaSe OnLy

[raccoon]

I just nailed down one of the bugs that causes an index to lose sync. I'm personally using Indexes->Folders for exFAT disks, but this bug might also extend to other Index-types and how they "Attempt to monitor changes."

If you rename a folder (a directory) to a different CaPiTaLiZaTiOn, but exactly the same string, then Everything will create a duplicate entry with the new CaPiTaLiZaTiOn but also keep the old capitalization. This does not affect file objects, only directory objects. When you further move or delete or rename the folder to a different spelling, the old entry remains stale and stays behind while the new entry receives the changes. (However, I have also observed where the new entry becomes stale and the old entry moves, I just can't duplicate this right now.)

Steps:
Create a folder named: TESTING FOO
Rename the folder to: TESTING foo
Rename the folder to: TESTING FoO
Rename the folder to: TESTING fOo
Everything now displays 4 folders when only 1 folder exists.

[NotNull]

I do not have any FAT64 volumes, but to help zoom in on the issue:

When reproducing these steps on a Folder Indexed NTFS volume (*), the folder gets renamed instantly every time in Everything.
(thanks to the Monitor changes setting)

Endresult = one folder: TESTING fOo



(*) ONLY Folder indexing; NTFS indexing was disabled for this drive.

[raccoon]

For testing, try formatting a free-gift USB flash drive to FAT32 or exFAT. I used exFAT in my test. Windows 7 64 Pro.

[NotNull]

For testing, try formatting a free-gift USB flash drive to FAT32 or exFAT.

Of course I already considered that. I simply do not have any spare at the moment (I always give them away)
(I even tried to mount an extra RAM disk and mount a virtual disk, but those didn't support exFAT filesystems ..)

But maybe someone else can test this?

[void]

Thanks for the bug report.

Everything was using the new folder name as the old folder name when renaming. Everything would think this folder was not renamed and add it as a new folder.
This would only occur for renamed folders/files that only had different case.

I've fixed this issue in Everything 1.4.1.958.

[raccoon]

Thanks void You're on fire!

updating

Out of curiosity, what did you find and how much other list damage was it probably causing so I can rule out those sync issues as fixed

[void]

It shouldn't cause to much of an issue as Everything would remove the old name at the next scheduled rescan.
Everything can handle files/folders with the same filename (with only different case) without issue.

[raccoon]

Indeed about the rescan. It's just that when I am (or was) performing meticulous librarian operations, making many a sweeping changes, that's exactly the same moment that I'm also using Everything. Not a half hour later.

But my question was about this bug is, what did you find, and how did you fix it. Like, some obvious crazy error that should probably fix all change monitor issues, or might there still be one or two rattling around in there? You said the bug affected both folders and files, not just folders.

[void]

Everything tries to resolve the Long File Name for Read Directory Change entries as these can sometimes use short filenames.

What this means is when you rename a file or folder, Everything would try to look up the long file name of the old filename.
This is a bug, as the old filename should not exist.
However, if the new filename is the same as the old filename (just different case) then the long file name lookup will succeed with the new filename.

Using a scheduled folder rescan should help keep your folder indexes up-to-date.
You can run Everything in debug mode to see all the detected changes.
Folder changes are shown in Teal starting with RDC.

This bug effects both files and folders.

[raccoon]

Cool, thank you. Btw, I'm pretty intimately familiar with Win32 API. I probably didn't mention that. I appreciate the explanation, and will try fuzzing for similar misbehaviors.

[raccoon]

This bug again (probably).

This time, when you Move a folder into a subfolder.

Example:

X:\foo\stuff\ moves to X:\foo\bar\stuff\

"stuff" starts a subfolder of "foo", and we move that folder into the subsubfolder of "bar" which is also a subfolder of "foo".

Edit: Doing this causes the folder and its contents to disappear from the index. (rather than becoming duplicated)

[void]

Thanks for the bug report.

This is a limitation of ReadDirectoryChanges.

The following events are fired when moving X:\foo\stuff\ to X:\foo\bar\stuff\:
DELETE X:\foo\stuff\
ADD X:\foo\bar\stuff\
MODIFIED X:\foo\bar\
MODIFIED X:\foo\

You can check this yourself by opening the debug console.

Everything doesn't know the folder was renamed. As far as Everything knows, the folder was deleted and a new one created.
I'll look into rescanning "added" folders..

[raccoon]

Everything doesn't know the folder was renamed. As far as Everything knows, the folder was deleted and a new one created.
I'll look into rescanning "added" folders..

Ah hah. Thanks for that explanation. And I like that solution.