Restoring window after file move / delete gives save dialog instead of open
Popular easy-to-use and secure password manager
Brought to you by:
ronys
Menu
▾
▴
#1448 Restoring window after file move / delete gives save dialog instead of open
If the currently open safe is moved or deleted while the app is minimised, a SAVE dialog is shown, and prompts to create a new safe rather than opening an existing one. This is surprising behaviour, and I nearly overwrote my password safe by mistake as a consequence.
Environment:
PWSafe V3.44, Windows 10, 64-bit
Steps to reproduce:
1) Create a new safe, named test.psafe3
2) Minimise the UI to tray while safe is open
3) Rename test.psafe3 to test2.psafe3 in Windows Explorer
4) Restore the app.
5) A prompt is shown "X:\test.psafe3 Can't open file. Please choose another" with a single "OK" button
6) Clicking OK pops up a file selection dialog. The dialog's title is "Please choose a name for the new database", but I was expecting an Open dialog based on the previous message, and overlooked this.
7) Selecting an existing pwsafe3 file asks if you want to overwrite that file. Doing so destroys the file and replaces it with an empty password safe!
The best behaviour here would probably be to simply close the current file, and return to the application's default screen, from which the user can choose to open a different safe or create a new one.
I couldn't reproduce this using the steps outlined here. You should probably provide more details about what you did after you create the safe but before it was minimized to tray. For example, was the safe in a state with unsaved changes?
I tried the following:
1. create safe
2. add an entry in safe but left safe with the changes unsaved.
3. minimize the UI to tray while safe is open
4. rename safe in Windows explorer
5. restore the app
6. make some more changes to the entry
6. Save the safe
7. exit PWS
I never got the prompt. After exiting PWS at step 7, there were now two safes the one with the original name and the one with the name it was renamed to. The one with the original name contained all the changes I made to the safe. The one that has the renamed name had no entries in it.
Hi, thanks for testing. I didn't do anything else other than creating a completely blank safe, and can reliably reproduce this with exactly the steps listed above.
I have "lock safe on minimize" enabled, so maybe step 2 should be "lock the database" rather than "minimize the window" - the point being that restoring the window would normally pop up the "enter your combination" prompt in order to unlock the current database.
Okay. I can reproduce this now after I enabled lock safe on minimize, which I normally don't have enabled. I agree with you that a return to the application's default screen, from which the user can choose to open a different safe or create a new one would be the best option.
However, I also saw other 'write error' issues with renaming or moving a safe that is in use, so moving or renaming an in use safe is not something I would do (unless by accident), nor recommend.
In that case, maybe the application should hold a lock on the file, so that the user can't rename or delete it until they close it. That's probably a "both and" rather than "either or", though, because there are scenarios locking the file can't fix, like a removable drive being unplugged or a network share disconnecting.
I'm no developer, but that seems like a good idea to address this issue.
Last edit: MrMe 2017-11-26
Changed behavior to be more explicit: Prompt user for Search, New, Exit, as we do in other places.
Fixed in commit e2230f0c5, will be in 3.47.
Released with 3.47.0