sumatrapdfreader
Renaming a password-protected file should update the storage of password, too
I open a file, enter the password, check "remember the password for this document", and it loads. I look for the version number, press F2 to rename the file and append the version number (or whatever) to the filename. Close the file, reopen it, and it asks for the password again because the file name has changed. The filename change should apply to the password storage too.
remember per document is as you found a hash based for the named entry,
FilePath = C:\Data\K\pdf-example-password=test.pdf
DecryptionKey = 31fbfcaf860bf3d74fcb95a645f62a335b5502dfe27b9524f0fede0730cc4b8000000000000000000000000000000000
for more widespread useability it can be stored as plain text
password=test
but both defeat the point of a password which for PDF is simply delay access, since it does absolutely nothing else, unless used in Acrobat where it can say stop you reading aloud etc.
Oh it stores a hash based on the filename? So it can't be done?
Yes passwords are stupid and I wish the files didn't have any in the first place
NO the hash is not based on filename that is a hash of test simply located as desired for each filename so another file same hash
FilePath = C:\Data\K\pdf-example-password=test - Copy.pdf
DecryptionKey = 31fbfcaf860bf3d74fcb95a645f62a335b5502dfe27b9524f0fede0730cc4b8000000000000000000000000000000000
however if the file is manually renamed or renamed by system it needs to be added once more
@kjk since the key is stored per filename then I dont think sumatrapdf could be expected to know a file by any other name is just as similar, and the use of global text passwords seems good enough as a fallback provision
the only way I see this request could be met is to move Decription Keys to also be stored/used as global ??
since the key is stored per filename then I dont think sumatrapdf could be expected to know a file by any other name
I don't get why the content of FilePath could be replaced with the new name.
@koppor it can be edited in settings because only the user knows what renaming occured in the filesystem OUTSIDE of SumatraPDFs ken, when renaming a file SumatraPDF is not given such feedback,
I see from your other question that the expectation is that on rename of a file there should be a form of traceback but that's often not the case in a simple hand over method.
For SumatraPDF to keep tabs on the change of a filename it would need to provide a more complex suite of actions such as copy/rename file to new name (remove old file system entry) and edit settings to match.
@koppor it can be edited in settings because only the user knows what renaming occured in the filesystem OUTSIDE of SumatraPDFs ken, when renaming a file SumatraPDF is not given such feedback,
At the end of the long first sentence, it is said, that the user presses F2 INSIDE SumatraPDF. In this case, SumatraPDF really knows that a file was renamed. In this case, SumatraPDF can update its store of stored passwords. It really knows that a rename happened, because it renamed it itself. As a consequence, it can look up the filename in the internal store. If it is there, it can rename the key in the store, too.
@koppor For F2 it does do that correctly in my tests using current pre-release.
Setting file holds first filename with remember data and remember password. F2 to another name that is the file that is open on rename. Settings file is updated (plus its password) to new name for next session.
Thus in theory this issue is closed. For a case that does not work a sample file and steps to repeat are needed.