You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The rationale for supporting modification times is as follows.
File-level syncing has risks. These risks include losing access to all of your passwords. A single bit error in a saved file could/should cause a checksum error in an encrypted file. Such an error makes the entire file unreadable. If this file is blindly propagated at the file-level, whether by sneaker-net or cloud storage apps, all devices will lose access to all passwords.
Single bit errors can happen for many reasons, bad memory on a computer, bad drive or thumb drive, unreliable internet connections, caching problems with cloud storage, OS updates breaking apps, etc. If you search the internet for keepass and sync errors you will see that the list never seems to end.
However, while other solutions can be proposed, such as telling each and every family member to make regular backups (will everyone do it religiously?, will I always?), one solution is appealing: namely to have one of the devices run a database manager (alongside PfP) that supports entry-by-entry sync; I'll use the original KeePass application as an example of this. KeePass supports, entry-by-entry sync. And the sync can be from multiple files saved at different times and from different devices. All conflicts will be resolved as long as modification times are respected by developers. Then after incorporating all changes in KeePass, that file can then be blindly replicated to all other devices without fear of complete loss of all passwords and site data.
Should a kdbx database file contain one or more bit errors during KeePass' entry-by-entry sync, the sync is aborted saving the integrity of the file stored locally on the KeePass machine. All that is lost are the updates in the bad file. This file stored locally on the KeePass instance should be treated as immutable / export-only / and excluded from blind file-level syncing.
With this as one solution, files can then be automatically and blindly synced at the file level for all other machines except for the KeePass/PfP machine. This can be done with Syncthing, cloud storage, or other. (For now I've been using LocalSend, which is cross-platform FOSS and works beautifully while keeping all kbdx files offline and away from any cloud storage provider.) When something goes wrong, there is a way to recover without manual entry by entry procedures.
TL:DR ... Entry-by-entry syncing, and its advantages, can coexist with PfP without PfP being responsible for them. They can be done externally with another application. However, this is only possible if PfP supports modification times on changes and new entries. Users who understand the need for, or insist on, entry-level syncing can still use PfP.
The text was updated successfully, but these errors were encountered:
The rationale for supporting modification times is as follows.
File-level syncing has risks. These risks include losing access to all of your passwords. A single bit error in a saved file could/should cause a checksum error in an encrypted file. Such an error makes the entire file unreadable. If this file is blindly propagated at the file-level, whether by sneaker-net or cloud storage apps, all devices will lose access to all passwords.
Single bit errors can happen for many reasons, bad memory on a computer, bad drive or thumb drive, unreliable internet connections, caching problems with cloud storage, OS updates breaking apps, etc. If you search the internet for keepass and sync errors you will see that the list never seems to end.
However, while other solutions can be proposed, such as telling each and every family member to make regular backups (will everyone do it religiously?, will I always?), one solution is appealing: namely to have one of the devices run a database manager (alongside PfP) that supports entry-by-entry sync; I'll use the original KeePass application as an example of this. KeePass supports, entry-by-entry sync. And the sync can be from multiple files saved at different times and from different devices. All conflicts will be resolved as long as modification times are respected by developers. Then after incorporating all changes in KeePass, that file can then be blindly replicated to all other devices without fear of complete loss of all passwords and site data.
Should a kdbx database file contain one or more bit errors during KeePass' entry-by-entry sync, the sync is aborted saving the integrity of the file stored locally on the KeePass machine. All that is lost are the updates in the bad file. This file stored locally on the KeePass instance should be treated as immutable / export-only / and excluded from blind file-level syncing.
With this as one solution, files can then be automatically and blindly synced at the file level for all other machines except for the KeePass/PfP machine. This can be done with Syncthing, cloud storage, or other. (For now I've been using LocalSend, which is cross-platform FOSS and works beautifully while keeping all kbdx files offline and away from any cloud storage provider.) When something goes wrong, there is a way to recover without manual entry by entry procedures.
TL:DR ... Entry-by-entry syncing, and its advantages, can coexist with PfP without PfP being responsible for them. They can be done externally with another application. However, this is only possible if PfP supports modification times on changes and new entries. Users who understand the need for, or insist on, entry-level syncing can still use PfP.
The text was updated successfully, but these errors were encountered: