Bitten by PM workflow hazards

[devenh]

For me, PM has two major workflow hazards:

1. Search and Replace has no undo.

2. You can all too easily delete a directory that you think is empty because your filtered view of is shows nothing.

I'm well aware of these hazards and have designed my workflow to protect against mistakes with multiple levels of protection.

Well, you know what is coming, right?

Last night, after three days of shooting and processing, I discovered about 300 images missing.  By this time though, I had already refreshed my primary backup (making a mirror image), so these 300 images were "lost" there too.  I was never at risk of losing the images as I had three other full copies of the original files, but the metadata edits I had made could be gone.

There is a happy ending.  I was able to completely recover the deleted images from my backup drive using an undelete program.

Nevertheless, I would like to repeat my requests for the following two features that would greatly reduce the risk of future mistakes:

1. Search and replace undo capability.

2. PM to warn you if you are deleting a directory that has filters active or "Show unknown files as proxies" is unchecked and if either of this is actually hiding files from view.

Deven

[Kirk Baker]

Deven,

For me, PM has two major workflow hazards:

1. Search and Replace has no undo.

2. You can all too easily delete a directory that you think is empty because your filtered view of is shows nothing.

I'm well aware of these hazards and have designed my workflow to protect against mistakes with multiple levels of protection.

Well, you know what is coming, right?

Last night, after three days of shooting and processing, I discovered about 300 images missing.  By this time though, I had already refreshed my primary backup (making a mirror image), so these 300 images were "lost" there too.  I was never at risk of losing the images as I had three other full copies of the original files, but the metadata edits I had made could be gone.

There is a happy ending.  I was able to completely recover the deleted images from my backup drive using an undelete program.

Nevertheless, I would like to repeat my requests for the following two features that would greatly reduce the risk of future mistakes:

1. Search and replace undo capability.

I can't think of any reasonable way to do this since the files are modified during the operation.  Undoing any metadata changes would require recording the state of the files prior to the replacement and the ability to back out of the changes, replacing the updated metadata with the recorded metadata, even then it may be impossible to restore the file to exactly the previous state, byte for byte.

2. PM to warn you if you are deleting a directory that has filters active or "Show unknown files as proxies" is unchecked and if either of this is actually hiding files from view.

Deleting a directory via the Favorites or Navigator?

-Kirk

[devenh]

I can't think of any reasonable way to do this since the files are modified during the operation.  Undoing any metadata changes would require recording the state of the files prior to the replacement and the ability to back out of the changes, replacing the updated metadata with the recorded metadata, even then it may be impossible to restore the file to exactly the previous state, byte for byte.

I can see why it would be desirable to restore the file to the exact state before the change was made, and I would certainly like this, *but* if I am given the choice of not being able to undo a mistake or being able to undo a mistake and have the file slightly altered, I'd choose the latter in a nanosecond 

But let's think slightly out of the box.  Why write the changes to the metadata immediately?  PM already has the ability to read/write metadata to XMP files.  Why not have the option to save search and replace changes to a temporary PMX sidecar file?  (The PMX file would be an XMP file of the yet to be committed changes) The user is then given a chance to inspect the changes and then commit them.  Once committed, PM would read the PMX files and write them to the RAW and/or XMP files, and finally delete the PMX files.

Deleting a directory via the Favorites or Navigator?

Navigator.

Deven

[Kirk Baker]

Deven,

I can't think of any reasonable way to do this since the files are modified during the operation.  Undoing any metadata changes would require recording the state of the files prior to the replacement and the ability to back out of the changes, replacing the updated metadata with the recorded metadata, even then it may be impossible to restore the file to exactly the previous state, byte for byte.

I can see why it would be desirable to restore the file to the exact state before the change was made, and I would certainly like this, *but* if I am given the choice of not being able to undo a mistake or being able to undo a mistake and have the file slightly altered, I'd choose the latter in a nanosecond 

But let's think slightly out of the box.  Why write the changes to the metadata immediately?  PM already has the ability to read/write metadata to XMP files.  Why not have the option to save search and replace changes to a temporary PMX sidecar file?  (The PMX file would be an XMP file of the yet to be committed changes) The user is then given a chance to inspect the changes and then commit them.  Once committed, PM would read the PMX files and write them to the RAW and/or XMP files, and finally delete the PMX files.

Or we could put them in a small database.  But then there would need to be an additional 'commit' command that the user would have to remember to execute, and I can see that this would create support issues for people who forget to commit their changes and switch out of PM and continue to work with their files and then find out that they don't have their changes.  Depending on what the user does in another app, they may never discover that the changes didn't 'stick.'

I like your idea, but it just doesn't solve the original problem cleanly enough in that it creates a set of new problems.

-Kirk

[devenh]

I see your points.  But please fix the delete directory issue.  That should be pretty straightforward to address.

Regarding search and replace, here are a couple of thoughts:

To avoid confusion, keep the current behavior, but have an option to enable previewing the changes and then committing them.  Any image that has a pending commit would be identified with a marker like the one used to indicate that the file had been uploaded (but with a different color).

Another option would be to add a Preview button to the Search and Replace dialog next to the Replace button.  There are a number of ways this could work after pressing Preview.  One would be that the Preview button would be relabeled Commit.  The user would then have a chance to inspect the changes and then press the Commit button.

Again, I do see that this could be confusing to some.  But I have to believe that a lot of users have made Search and Replace mistakes and would appreciate some easy way to recover.

Deven