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

[weidmic]

It depends...

Just a few thoughts


What does it mean being IN SYNC?
To me that the data in the database and the data that in the image is Identical (I am talking only about the data that is handled and touched by PSU)

So, after I synced an image there should be no need to have the old hash on file anymore, because all that has to be done is done...

You are absolutely right that there are cases that can generate a conflict. That is where the old hash could come into play.
But before a image is being synched!

In case of a conflict I would expect that the application is asking me what I want to do.
Something like: The metadata has been changed in PSU and the metadata in the actual image file. What do you want me to do?


That is exactly what my backup software is doing...

Regards,
Michel

[Hert]

What does it mean being IN SYNC?

In-Sync is completely different. A signature is not an identifier that tells you if a file is in-sync or not. A signature tells you what the *file* is, it doesn't care about sync states or whatever. That is handled differently.

To me that the data in the database and the data that in the image is Identical (I am talking only about the data that is handled and touched by PSU)

True, but that is not what a signature reflects. A signature is a snapshot code that represents the file bytes. It's intended to tell you if a file is changed or not. Exactly what you backup software also does.

Can we please keep the topic on target: auto update or not and if yes then why, and did you consider the consequences. Right now it seems like you don't exactly understand what signatures are.

Hert

[weidmic]

Hert, I totally know what a signature is!

Can we please keep the topic on target: auto update or not and if yes then why, and did you consider the consequences.

I don´t know, but maybe my English is not good enough for you to understand what I am saying...

Regards,
Michael

BTW: Please read my post closely; I have just brought up a thought on how the hash could be used in an environment where the hash is being updated automatically...

[Hert]

I did read it thoroughly, and your English is very good. But I think you are mixing the concepts of "insync" and "verification". They are not the same; a verified file doesn't mean that it is "insync".

So, after I synced an image there should be no need to have the old hash on file anymore, because all that has to be done is done...

And this is exactly why. The signature is still valuable after all work that is to be done is done. For instance to detect corruption or if some other software altered the file.
Especially after all done is done, the signature has the highest value because it helps you to find those files that were altered or corrupted *without* you knowing.

Again, I could enable auto-updating; in fact this is already prepared ever since MikeP first raised it in his ticket, but never enabled it because I'm not convinced that this is the way to go. Reason as explained earlier: the file could already be altered when making changes to the file and then the signature would be updated and you'd lose the fact that the file was already altered. I very much do see the argument that it would be a lot easier; and maybe that's enough reason to do so.

Hert

[weidmic]

My thoughts again on this (and why):

Using Save: I tell PSU that I want everything is being written to the file. When I use save I must be aware of the fact that I might overwrite metadata in the file altered by other software - update the hash

Using Read: I tell PSU that I want everything from the file my database. When I use read I must be aware of the fact that I might overwrite metadata in my database -
[EDIT]Don´t update the hash because there is no file change anyway [/EDIT]

Using Sync: you could bring in the hash to avoid conflicts. The hash should not be a trigger that a image is not in synced,
but a instance of security; to make me the user aware of the fact that the file signature is not anymore the same (before the image is being synced and it`s too late to react)

Of course, the hashes would have to be updated once for all images in the database...

Cheers,
Michael

[Hert]

Michael, you still mix sync states with signatures. Like I said, they are unrelated. Sync save could lead to an updated file and you could want to update the signature then. reading would never! You keep confusing signatures with sync states.

Hert

[weidmic]

reading would never

right...

[mphillips]

Hi Hert and Michael

I think I am also confused

When I sync a file (after making a change in PSU) does the XMP sidecar file not get changed on the HDD?

And if it does should it not then get a new hash ? (because the contents have changed)

And if it gets a new hash should it therefore not show as unverified on the next file verify ?

Because I am not sure that this is presently what is happening

Regards

MikeP

[Hert]

When I sync a file (after making a change in PSU) does the XMP sidecar file not get changed on the HDD?
And if it does should it not then get a new hash ? (because the contents have changed)

Right. The question here is if the signature should be updated automatically or not.

And if it gets a new hash should it therefore not show as unverified on the next file verify ?

Right because the signature is different from what is in the database. And it also shows up as unverified!

Because I am not sure that this is presently what is happening

How you describe it is exactly how it works NOW. The topic is about...should the signature be updated automatically or not...but the topic keeps drifting off to synchronization etc. All I want to hear is "yes the signature should automatically be updated because...." or "no, it should not and stay the way it is, because".

Hert

[jcldl]

I read with attention all this discussion and I want to be sure I have understood. After "verify folder" if files have changed, I can:" Update file signature " if I think that the changes are real and already in the database. Nothing happens to the structure of database and nothing written to the files (picture+xmp or else); "Import data from file"if I think that files have been changed and I want to keep these changes in database;" Export data to file" if I think that database is OK and I do not accept the changes in the picture or xmp.
Am I OK?

[Hert]

I can:" Update file signature " if I think that the changes are real and already in the database. Nothing happens to the structure of database and nothing written to the files (picture+xmp or else)

Correct. And by updating the signature, you're telling PSU that you accept the file as it is.

"Import data from file"if I think that files have been changed and I want to keep these changes in database;"

Correct.

Export data to file" if I think that database is OK and I do not accept the changes in the picture or xmp.

Correct.

Hert

[weidmic]

To give you a clear answer: My vote is to automatically update the hash, because

that it would be a lot easier; and maybe that's enough reason to do so.

[mphillips]

Hi Hert

Right because the signature is different from what is in the database. And it also shows up as unverified!

Are you sure ? I have just tested and blow me down - they are set unverified - when did this change - I am sure this was not the behaviour from the beginning or I have just now noticed it.

Okay - to refocus the topic I FIRMLY believe that if PSU makes a change (via Auto Sync or Write metadata to file) then it should NOT show up as unverified.

I understand the file verify to mean "Changed by an outside program - PSU needs to update its internal database" - rather than "Some program - maybe PSU has made a change so therefore I need to update the hash", in essence the term "import data from file" means to me that changes have been made that I have to import - and the ONLY case where that would happen is is ANOTHER (not PSU) made the change. In Simple user terms I should never need to re import data if PSU made the change - Understand what I am trying to say here... SO if the message said "Update the File HASH for change tracking" then I would believe the processes at present to be correct - but I don't think it right at the moment - PSU should not set the file "unverified" (although I do understand what is presently happening)

Hert - maybe because most people (assumption here) are using File verify to "import" changes from outside PSU - that is why I am thinking like this.

If people were using File Verify to see if files had changed (for whatever reason) then i could see the present situation being right - but WHAT am I supposed to do with the message at the present - Import the data ? - What for - PSU is already up to date, No Action - well then I'll just keep getting the message, Export data to file - Why ? PSU should have written, Update File Signature - HUH / I just Syncv'ed (Okay - don't flame me - IIII know they are different but do all the novice users!) The only useful option would be "File has changed - back it up!" and thats not PSU's job.

So in summary - I believe that any change made my PSU should set the file as verified - then i can use this useful function to import changes from outside programs and update thumbs.

Regards

MikeP

[weidmic]

So in summary - I believe that any change made my PSU should set the file as verified - then i can use this useful function to import changes from outside programs and update thumbs.

YES, YES, YES and YES again

Regards,
Michael

[Mike Buckley]

All I want to hear is "yes the signature should automatically be updated because...." or "no, it should not and stay the way it is, because".

The signature should automatically be updated if the change is made by Supreme. That is because the user made that change and does not want to have to go to the trouble of separately updating the signature afterwards.

The signature should never be automatically updated if the change is made outside Supreme. That is because the change could be that the file has become corrupt. There would be no way to know that has happened if Supreme doesn't alert the user about that possibility. Another reason, as MikeP indicates, is that the change could have been intentionally made outside Supreme. It would be nice for Supreme to alert the user about that change that has not yet been imported into Supreme.