Indexed Property, update criteria?
what is the criteria used to determine when an indexed Property is updated?
say you indexed sha1, what would cause the index to update the sha1 value
for any particular file?
i'll assume something like when Index Journal notes a change in... size,
obviously, date, but not size, or ... ?
suppose there was no Index Journal or date or size change - yet the file
"did" change, say bitrot (or failing drive...) - that would not be detected
& would not update any sha1 value.
so .db has 1 value & if you were to compute the value of said file, & if
you then compared (newly) computed against stored .db, they would not
match - but... you'd never know, cause one is not going to do that...
Indexed Property, update criteria?
Re: Indexed Property, update criteria?
The following events will cause properties to be gathered (or re-gathered):what is the criteria used to determine when an indexed Property is updated?
The file is created.
The file is renamed.
Data was overwritten.
Data was extended.
Data was truncated.
Alternate data stream was overwritten.
Alternate data stream was extended.
Alternate data stream was truncated.
Extended attributes changed.
Security changed.
Indexable status changed.
Basic file information changed. (attributes)
Hard link changed.
NTFS Compression changed
NTFS Encryption changed.
Object ID changed. (shortcut tracking)
Reparse Point changed.
Stream Changed.
(you can filter the above events with usn_record_filter)
The file was selected and Ctrl + F5 was pressed.
The volume was reindexed.
Everything regathers properties on any change event.i'll assume something like when Index Journal notes a change in... size,
obviously, date, but not size, or ... ?
Everything ignores the size / date modified.
Size changes isn't enough, A change could be made where the size remains the same.
Typically, Date modified is reliable to detect changes, but it can be changed by programs.
Correct.suppose there was no Index Journal or date or size change - yet the file
"did" change, say bitrot (or failing drive...) - that would not be detected
& would not update any sha1 value.
I recommend sha256 sidecar files.so .db has 1 value & if you were to compute the value of said file, & if
you then compared (newly) computed against stored .db, they would not
match - but... you'd never know, cause one is not going to do that...
-or-
Backup your .db and compare property values.
Old db files can be opened from Everything -> File -> Open File List...