Many files have "changed". Which action is best?

[jstartin]

According to Verify, several thousand of my files have "changed". I thought that this result would only detect files where the metadata has been altered outside of PSU, but I am not aware of having done anything outside of PSU to cause extensive changes. All the files are shown as "in sync". Presented with a choice of "No Action", "Import Data from File", "Export Data to File", or "Update File Signature" I am unsure which option to take. Apart from the obvious step of backing up the catalogue, my inclination is just to update the signature, but first, does anyone have any advice on the best way to tidy up?

[Hert]

If you think that the files are not recently changed, then perhaps the dates of the files changed...maybe due to backup software that updated the attributes?

I would update signatures only too, but I'd still try to find out why the files changed.

Hert

[weidmic]

Jim,

last Time I did that I have updated the file signature... (That was about a week ago)
I just run the verify folder on the images I took in 2012 again. 4326 images out of 4824 are supposed to have changed....

Only thing I can say:
I don`t know what triggered PSU to say that the files have changed - and maybe something has changed. Maybe last accessed or whatever...
But I am sure, nothing that should trigger a software to say that the file has changed. My Backupsoftware does not see any changes either

So, no clear advice from my side, but something to think about

Cheers,
Michael

[Hert]

and maybe something has changed. Maybe last accessed or whatever...

Oh something has changed! Last accessed should not make a difference. What I think could be the case is that you ran the earlier verify in a different timezone (Daylight saving) and that the dates stored are not in zulu dates (0-dates)

Hert

[Hert]

I double checked this and I thought that the file date was part of the hash....but it isn't .

The hash is created from the filename+file content. The file hash for a file is also a combination of the file hashes of sidecar files. So for a NEF file with an XMP sidecar file, the hash is calculated over the NEF+XMP file. So if the XMP file for a NEF changes then the file is also reported as changed

Hert

[weidmic]

Ahhhh...

Then no wonder that so many images are reported to be have changed!
I have saved the metadata from all images from 2012 to get the LR hierarchy written to the images (xmp-sidecarfile)
Almost all my images are NEF´s just a few are DNG`s and Jpg´s.

One question: when this has been correctted an I
Import Metadata
or
Save Metadata
or
Synch Metadata
from within PSU then the hash is going to be always updated and a verify would not pickup any changes. Is that correct?

Cheers,
Michael

[mphillips]

Hi Michael

I am just checking that I understand you.

When you made changes in PSU - you then said "SAVE METADATA" from the context menu - and that process did NOT update the hash so therefore the file was marked out of sync ?

If hat is in fact the case I think that is a bug - because in my mind any change that PSU makes to a file should NOT result in a File Verify report - because PSU has made the change - NOT and external program.

What are your thoughts - especially for an inexperienced user suddenly getting a report of thousands of out of sync images when they know that they did not change the file outside of PSU ?

I did submit this in mantis ages ago (id=1091) but have no response so maybe I am on completely the wrong track.

Regards

MikeP

[jstartin]

In my case (opening post) I think this may be a result of changing synchronisation preferences. Following forum discussion a week or so back I switched from delimited keywords to Lightroom hierarchical keywords and explicitly exported everything to file again to get all files "in sync" with the new preference. If this does not update the file signature, then I think that is a mistake.

The next problem is that updating the file signature seems to be one of the verify actions that stalls (the activity panel stops updating) unless the mouse is moved from time to time. Getting through a few thousand images is turning out to be tedious.

[weidmic]

Mike,

Best would be to wait for the next update and see what Hert says about the Hash-Formula
My thinking is easy: after a read/write/sync the hash needs to be updated so that no action is triggered be a "verify folder".
Only a change made outside of PSU (and not picked up automatically by PSU) should propose a action after a rescan.

Cheers,
Michael

[Hert]

Best would be to wait for the next update and see what Hert says about the Hash-Formula

I just explained how it works now, so I don't see what the "wait for Hert" is for

Hert

[weidmic]

Sorry Hert, but I have read it now a few times, but to me it is still not definite clear.

[weidmic]

One question: when this has been correctted an I
Import Metadata
or
Save Metadata
or
Synch Metadata
from within PSU then the hash is going to be always updated and a verify would not pickup any changes. Is that correct?

Hert, can you answer this question?

[Hert]

Right now signatures are not updated by the app.

Hert

[weidmic]

Hert, my question was not about the presence. I asked how it will be in the future...

Michael

[Hert]

I'm not totally convinced that it's best practice to auto-update signatures.

Imagine this;
1. A file is changed outside of the application with PSU closed
2. Now in PSU the file gets a new rating (or label or whatever) and is synced.

When auto-updating then at this point the signature will be rebuilt. But fact is that the change made outside is not ever handled. And the file won't show up anymore in verification results.

If one could assume that the stored signature is correct (like you do in your reasoning) then it sure would make sense to auto-update the signature...hence the request. But did you also think of what if the file was *already* changed (or corrupted on disk for whatever reason) and the current stored signature is not up-to-date (read the file should be signaled).

And then when you find out that that image is corrupt you would blame PSU for not signaling the file during verification, simply because you continued working with the software and signatures are updated automatically

The verification service should be seen as the independent controller. It just signals that things have changed since *you* last ran it and it doesn't matter who did it. It signals to you and you should decide what to do. Even when writing the file with PSU, the file could in theory be corrupted.

Hope you now see that auto-updating signatures is not always a good idea, it's only a good idea in a perfect world...but the verification service is intended to detect the imperfections.

Hert