refactor: Don't include email addresses in export filenames - #8626
refactor: Don't include email addresses in export filenames#8626j-g00da wants to merge 1 commit into
Conversation
a298f0a to
6ad24a5
Compare
j-g00da
changed the title
6ad24a5 to
78983c2
Compare
Changes filenames used in the db backups and key exports, preferring fingerprint over the email address. Part of: #8572 Signed-off-by: Jagoda 艢l膮zak <jslazak@jslazak.com>
78983c2 to
26fbf9e
Compare
|
Do we want to include display name in the filenames? I didn't do so as this may be problematic. If we were to, it would make sense to at least somewhat sanitize these strings (at least removing slashes, backslashes, and all kinds of whitespaces). I'm not sure if we actually want it though, display name can be changed and this WILL affect ordering, which can be problematic. Since fingerprint is the actual identity, I think it should be accessible from the UI. |
| /// written to temp_db_path. The backup can then be written to temp_path. If the backup succeeded, | ||
| /// it can be renamed to dest_path. This guarantees that the backup is complete. | ||
| /// | ||
| /// `addr` is no longer included as part of the file stem, and is only required to calculate |
There was a problem hiding this comment.
This will not work if the user changes the sending address, and this way we do not get rid of the get_primary_self_addr call. There is a date in the backup filename prefix, so it should be ordered correctly already. So i think it's fine to already drop the address even here.
There was a problem hiding this comment.
as long as it's not made on the same day - but maybe it's a negligible edge case
There was a problem hiding this comment.
User making two backups on the same day, one with old version and another with a new version, is definitely an edge case. Also the goal is getting rid of get_primary_self_addr (we want to get rid of the concept of primary address) and currently the PR still calls it.
There was a problem hiding this comment.
I can just do the same check I do right now, but taking into account all addresses, this would cover this edge case and won't rely on "primary" addr. Also would cover the pre-existing bug when changing the sending addr.
There was a problem hiding this comment.
Checking against all address will do if you want to do it, but IMO not worth the complexity since this code is not going to be used day after the user upgrades.
It may be useful in case user exports multiple backups, but i think better not do it now, and not in this PR. Most users probably don't do any backups and having multiple devices is sufficient for backing up profiles, have not even seen any user questions about backups recently. |
2 participants
Changes filenames used in the db backups and key exports,
preferring fingerprint over the email address.
Part of: #8572