i want to see what the previous synced state of the file was to compare it to the new state so i run fix:
$ snapraid fix -f /media/video/tv/Show/S05/season.nfo
Self test...
Loading state from /home/kinghat/.snapraid.content...
Searching disk disk0...
Searching disk disk1...
Searching disk disk2...
Searching disk disk3...
Searching disk disk4...
Searching disk disk5...
Selecting...
Using 1090 MiB of memory for the file-system.
Initializing...
Selecting...
Fixing...
100% completed, 2 MB accessed in 0:00
Everything OK
if i run diff again, it shows that the file is still updated 🤔
Last edit: kinghat 2024-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i renamed the file and then did the diff which showed it was removed. then i did the fix on it and it restored it with the timestamp from the last sync state like i thought it would. there were no differences between the two files, only the timestamps.
im not sure if that is a bug but probably they way it works. i feel like if it thinks its updated it should be able to be restored.
a nice feature would be to be able to fix to a different location.
Last edit: kinghat 2024-05-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The key to your confusion is that the fix command does not write/modify the content files.
In your scenario where you "preserved" the state of your updated file by renaming it, and then doing the fix, you were able to verify that the timestamps alone were the cause of the diff report.
If you wish to actually commit the results of a fix command, to your array (i.e., have a record of those results reflected in your content files), you need to then do a sync.
Last edit: UhClem 2024-05-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you wish to actually commit the results of a fix command, to your array (i.e., have a record of those results reflected in your content files), you need to then do a sync.
i just wanted to be able to check if there was a different between the synced state of the file and the updated state of the file, other than the timestamps. when i was able to get the synced state of the file via my workaround, i was able to manually diff the contents of the two states and see that they were the same.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A fix should revert the file to the state of the last sync - this would include the timestamp and a diff shouldn't show any differences after a fix (as the file should be identical to the last sync state after fixing... the diff comparing to that last sync state as well after all).
The whole point of fix is to make the file hash-identical to the last sync state. Whenever I fix files, no diff is shown afterwards and certainly no sync is needed (unless I am changing the whole disk and need to update the content file with the new UUID). Why would the content file need updating if the file is reverted to the last sync state, which the content file should already reflect?
In fact if you sync now you will sync the still not-identical, changed file and will be unable to recover the previous "correct" sync state version of that file anymore.
This is how a fix log looks for me on an intentionally changed file:
are you saying their might be a bug in fix? because imo it should have restored the last synced state regardless of the timestamp. otherwise updated and fix arent congruent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, if the file didn't change content-wise (hash-wise) and only the time-stamp did (the time-stamp not affecting the hash) there's nothing to fix (as the file is identical to the last sync state content-wise) but the file will still show as updated until you next sync because diff checks time-stamps and not file content (hashes). If you run a check on the file it'll come back as OK if the content is unchanged, even if the time-stamp is different. So you need a sync to apply that timestamp change, if you are sure the content is identical (by previous check) and what you want.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
P.S. If you do not want to sync, you can also delete the file and run a fix on the file afterwards. That will recreate the file with the old timestamp and a diff will show no differences even without a sync - as timestamp and content will now be identical to the previous sync state.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
this is what i wanted to do to be sure the two states were identical(not including the timestamp). a "force fix" or some way that denotes that its just a timestamp change in updated list would be nice.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Next time instead of manual comparison you can just run a SnapRAID check on the file in question, if it comes back OK then the content is identical and you can sync the timestamp change.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
a diff revealed an update to a file:
i want to see what the previous synced state of the file was to compare it to the new state so i run fix:
if i run diff again, it shows that the file is still updated 🤔
Last edit: kinghat 2024-05-20
i renamed the file and then did the diff which showed it was removed. then i did the fix on it and it restored it with the timestamp from the last sync state like i thought it would. there were no differences between the two files, only the timestamps.
im not sure if that is a bug but probably they way it works. i feel like if it thinks its updated it should be able to be restored.
a nice feature would be to be able to fix to a different location.
Last edit: kinghat 2024-05-20
The key to your confusion is that the fix command does not write/modify the content files.
In your scenario where you "preserved" the state of your updated file by renaming it, and then doing the fix, you were able to verify that the timestamps alone were the cause of the diff report.
If you wish to actually commit the results of a fix command, to your array (i.e., have a record of those results reflected in your content files), you need to then do a sync.
Last edit: UhClem 2024-05-21
i just wanted to be able to check if there was a different between the synced state of the file and the updated state of the file, other than the timestamps. when i was able to get the synced state of the file via my workaround, i was able to manually diff the contents of the two states and see that they were the same.
Honestly, I think something went wrong here.
A fix should revert the file to the state of the last sync - this would include the timestamp and a diff shouldn't show any differences after a fix (as the file should be identical to the last sync state after fixing... the diff comparing to that last sync state as well after all).
The whole point of fix is to make the file hash-identical to the last sync state. Whenever I fix files, no diff is shown afterwards and certainly no sync is needed (unless I am changing the whole disk and need to update the content file with the new UUID). Why would the content file need updating if the file is reverted to the last sync state, which the content file should already reflect?
In fact if you sync now you will sync the still not-identical, changed file and will be unable to recover the previous "correct" sync state version of that file anymore.
This is how a fix log looks for me on an intentionally changed file:
Afterwards running a diff shows zero differences, the old file timestamp and identical hash from when the file was still OK (before my changes).
Last edit: Rysz 2024-05-21
are you saying their might be a bug in fix? because imo it should have restored the last synced state regardless of the timestamp. otherwise updated and fix arent congruent.
No, if the file didn't change content-wise (hash-wise) and only the time-stamp did (the time-stamp not affecting the hash) there's nothing to fix (as the file is identical to the last sync state content-wise) but the file will still show as updated until you next sync because diff checks time-stamps and not file content (hashes). If you run a check on the file it'll come back as OK if the content is unchanged, even if the time-stamp is different. So you need a sync to apply that timestamp change, if you are sure the content is identical (by previous check) and what you want.
P.S. If you do not want to sync, you can also delete the file and run a fix on the file afterwards. That will recreate the file with the old timestamp and a diff will show no differences even without a sync - as timestamp and content will now be identical to the previous sync state.
this is what i wanted to do to be sure the two states were identical(not including the timestamp). a "force fix" or some way that denotes that its just a timestamp change in updated list would be nice.
Next time instead of manual comparison you can just run a SnapRAID check on the file in question, if it comes back OK then the content is identical and you can sync the timestamp change.