Empty hash property if it's been modified?

[Herkules97]

Is there a way to empty SHA-256 when the file has been modified so it doesn't sit with an old value?

[therube]

Don't recall all the factors that will cause a re-read of the Property,
but you could do something like rename the file (then revert, Ctrl+Z, that change back, if desired).


(Now, of course you have to know that the hash is incorrect.
Potentially (& in practice), malware could hide itself by modifying a file, retaining date/time/size... which would go undetected.)



Here it is, Indexed Property, update criteria?.

[Herkules97]

Because your post was modified while I was writing mine, here is the original reply-to:

Don't recall all the factors that will cause a re-read of the Property,
but you could do something like rename the file (then revert, Ctrl+Z, that change back, if desired).


(Now, of course you have to know that the hash is incorrect.
Potentially (& in practice), malware could hide itself by modifying a file, retaining date/time/size... which would go undetected.)

Idk why your bring up modifying a file to re-read it.
If X file gets X hash, then X file becomes Y file, X hash remains until somewhere in the queue it updates.
This was already established in my title.

How are hashes with EBV relevant to malware and how does it help that the hash remains the old one if malware modifies a file? Confused

Maybe other extra properties don't need to be cleared, but hash will always be different after a modification. SHA-256 specifically hasn't been known to collide and even if it does, it's essentially never happening on a random user's system.
This wouldn't apply to files that EBV can't read from such as in-use files that never release until program exits.
They will have their old data until program exits, so the hash is accurate too. The file itself isn't accurate in EBV compared to the live file, but that's different issue. All properties are accurate to the version EBV does have indexed, in other words. Unless it gets modified right at the start of the program running, but then it would have cleared the extra properties as it detected a change.

A manual way could be Ctrl+F5, but it clearly hasn't added stuff to the front of the queue ever.
I also think Ctrl+F5 even if it doesn't work all that correctly, should clear the values. To make it clear it's not read the files yet.
This clearing could be done as soon as you use ctrl+F5 and could be a toggleable setting in advanced options so if you want old property values you can keep them.
Generally only the hashes should be different, so maybe you could have 2 settings. One clears all extra properties, the other only clears hashes. I'd use the first one as the point is to clear any values that could be different and are extra properties. The basic ones such as size and datetime created are updated either way so they should always be up-to-date unless there are bugs.

With the automatic method, you'd know what files to ctrl+F5 before export. Ctrl+F5 would still have to be modified to clear properties and hopefully also make it so it puts those files first. It might put the files NEAR the start of the queue but that can still take 10min. It should put them AT the start of the queue so they're immediately being re-gathered.

The "gather_properties_on_export" setting is useless in this scenario as it apparently doesn't do what it's supposed to and only applies to selection-only. So if you want to re-gather for the entire list, you have to add one extra file that you then de-select after selecting everything?
Anyway, it doesn't work as expected. If EBV has an old value for the file, it'll seemingly treat that as having a property value and not re-read it.
"refresh_on_read_extended_information" also does nothing, which I suppose makes sense as it references the action that only re-reads the basic properties or at least some of them.

With the addition of the last part:

Here it is, Indexed Property, update criteria?.

I removed the part about what it will use to know a file has been modified

[void]

Is there a way to empty SHA-256 when the file has been modified so it doesn't sit with an old value?

No.

A manual way could be Ctrl+F5, but it clearly hasn't added stuff to the front of the queue ever.

Ctrl+F5 in the next update will add requests to the front of the foreground queue.

The "gather_properties_on_export" setting is useless in this scenario as it apparently doesn't do what it's supposed to and only applies to selection-only. So if you want to re-gather for the entire list, you have to add one extra file that you then de-select after selecting everything?

gather_properties_on_export only works for unindexed properties.
It doesn't gather properties for indexed properties, even if they haven't been gathered yet.
You'll have to wait for property indexing to complete before exporting.

[Herkules97]

You'll have to wait for property indexing to complete before exporting.

Can't wait for it cause I can't know when the values are correct.
If the hashes store their old values, I just have to hope they are accurate at the moment I export.

Ctrl+F5 actually putting selected items first will surely help. But nothing will beat the property values being emptied to accurately reflect the state of the file in the index.
If it were to clear it, ctrl+F5 could then be used to force it only on the files that lack up-to-date hash, presuming property delay doesn't apply to ctrl+F5. Surely the queue is unaffected by the delay, so even if a file was modified within 10 seconds and you ctrl+F5 it will immediately start on it with a property delay of 10min?

Maybe this isn't as relevant when the index is sort of up to date. As SHA-256 hashes are still in a big queue and won't be done for at least 2 months looking at the speed it's been at so far, maybe it won't be so bad later.
But this will require ctrl+F5 to place stuff at the front of the queue so I can see the hashes update.

If there was a timestamp for when a hash was gathered this could also be achieved with good accuracy I imagine. Like !disha-256:=<2026-10-26T18:00 to exclude any files that have had SHA-256 indexed before that time. "Date-indexed-sha-256:=>" unabbreviated di.
But that would be add extra RAM over a "modified" file being cleared of the hashes and maybe other extra properties.

Without clearing but with ctrl+F5 putting stuff at the front, I will have to use some properties that are less accurate to when the file has been "modified" such as size and date modified. Datetime modified within say 15min will be refreshed and anything above maybe 10MB within 30min just in case their sizes have delayed it for longer.
Maybe also refresh any filetypes that are known to not necessarily change these, like certain database files. Particularly the size of them such as Firefox's places.sqlite only growing by 5MB whenever it has actually grown by that amount.

Alternatively I get rid of the delay but then it's more likely to get stuck on files that have been recently modified. Or at least occupy reading the same files over and over. That seemed to be the case, as I kept seeing the same files in the progress bar's tooltip until I introduced the delay.
It's currently at 10min, I previously wrote 30min but that was reduced early on and I forgor. I also read it as 60K ms and read that as 30min..But it's 600K ms for 10min.