Date Modified wrong?

[larifari]

Hi!

Two screen shots:

explorer.jpg (18 KiB) Viewed 7859 times

Everything.jpg (14.19 KiB) Viewed 7859 times

Date modified shown in Everything is wrong. The file was modified just a few days ago. I find that this has been an issue several years ago. I'm using Everything v1.4.1.935 (64x). 2019-12-14 is quite close to the day I installed Everything on this desktop.

Am I missing something?


Thank's fro reading, larri

[therube]

Is the file always held open?

I have a program that uses a license manager.
License Manager opens a log file.
Log file that was backed up is the size - at some point in time - but smaller then what exists (currently) on disk (the source file).
...
'm thinking, that perhaps once a day (once the day changes, so from 18th to 19th, to 20th), something gets written, sync'd if you will, such that a "file change" is "recorded", & at that point, FFS will then pick up that change & write it out to the backup. (But throughout the day, it, its logs, only note that something is amiss.) (License manager typically runs 24/7... If it were to be shut down, I'm sure the change would be picked up immediately.)


(Similarly, but slightly differently, again, Everything (which reads from the MFT) has the particular file size & date/time, sized, & dated the size/date that its' database initially read the file, & does not see the newer, large size, later date. I suppose, if I were to force an update, it would pick up current data size/date & hold that from that point on... or until some action occurred "releasing" the file, at which point all would update, automatically.)

https://freefilesync.org/forum/viewtopi ... 299#p24861

[larifari]

Hi!

Thanks for your attention therube.

No, it's not kept open, it's read many times since. The app modifying it has been exited several times since too. Also Everything seems to read date/time accessed real fine. This is just a sample file, the issue applies to hundreds of files (if not all).

I tried replacing the "dm:" (date modified) option I used with "da:" (date accessed), but that's terribly slow.

Thank's for reading, larri

[void]

Everything may have a stale date modified in the index.

Please try forcing a rebuild:

• In Everything, from the Tools menu, click Options.
• Click the Indexes tab on the left.
• Click Force Rebuild.
• Click OK.

[larifari]

Hi!

Thank's void, that did the trick.

How can I avoid such a situation in future?
Any known 'best practise'?
Any method to proof if the db is stale?
Why are da: searches terribly slow at times?

So many questions ... [deep sigh]
I'd really love to use this tool, but its must be reliable of course.


Thank's for reading, lari

[NotNull]

How can I avoid such a situation in future?

Upgrade to Everything 1.4.1.969 or later. Improvements were made in this area.

Everything uses 2 special files of Windows to keep it's index up-to-date: the MFT and the USN Journal.
MFT (the "address book" of all files/folder) is read upon the initial scan of the filesystem (and during a Force Rebuild).
The USN Journal is a Windows logbook of all changes (create, update, rename, delete) made to the filesystem. It contains partial information.
One of the areas that is tricky for Everything are hard-linked files. Those are files that are stored exactly one time on disk, but have multiple names.
Large parts of the C:\Windows folder consists of hardlinks. You can check it using the fsutil.exe utility
Example: notepad.exe:

Code: Select all

 T:\>fsutil.exe hardlink list c:\Windows\notepad.exe
\Windows\System32\notepad.exe
\Windows\notepad.exe
\Windows\WinSxS\amd64_microsoft-windows-notepad_31bf3856ad364e35_10.0.18362.693_none_c4ba840b01c3d6f4\notepad.exe

If your SPJ62Z.xmp is a hardlink too, the USN Journal might report that one of the other filenames is updated and Everything will miss SPJ62Z.xmp (this behaviour of Everything will change in Everything 1.5, btw)


Another reason why Everything might miss updates to this .xmp file:
If the program that create this file saves it to a temporary location first, before moving/copying it to the final destination, Everything will miss this too if that temporary location is excluded from your Everything database as Everything misses the reference point.
If this happens again, check Menu:Tools > Options > Indexes > Exclude. You migh have excluded a crucial folder.

Why are da: searches terribly slow at times?

If this information is not in Everything's database, it will have to be read from disk. And that is slow, especially when a lot of files have to be processed.
Solution1: Minimize the number of files that have to be processed by expanding your search query (see here)
Solution2 (recommended): Include the date accessed information of files in the database:
- enable Index date accessed and Fast date accessed sort (Menu:Tools > Options > Indexes)

[larifari]

Hi NotNull!

Thank's million for this detailed explanation! I do appreciate your support.

Regards, larri