Summary: | Backup copies of all files are saved to a single folder | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | lvm <lmironov> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | buzea.bogdan, heiko.tietze, jluth, lmironov |
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.documentfoundation.org/show_bug.cgi?id=143038 https://bugs.documentfoundation.org/show_bug.cgi?id=89651 https://bugs.documentfoundation.org/show_bug.cgi?id=68565 |
||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 77999 |
Description
lvm
2022-07-26 07:37:59 UTC
(In reply to lvm from comment #0) > 1. If two or more files stored in different folders share the same name, > their backup copies overwrite each other, which effectively causes the loss > of backup. This is the real problem. > 2. Many people find it illogical and against the traditional approach when > backups are stored in the same folder as the original file. This is not a problem. Note that the function that you are talking about is not creation of *backup* copies (configured by "Options->Load/Save->General->Always create backup copy", and **created in the same directory as the original file**) - but creation of *autorecovery* information ("Save AutoRecovery information" in the same dialog). The problem here is likely the naming of the directory in "Options->LibreOffice->Paths"; it should not be "Backups", but "Autorecovery". > 3. Single folder with all the backups is cluttered and difficult to navigate. This is also not a problem, because that directory, as explained, is intended for internal purposes, should ideally be managed by the application, and cleared at successful close. We rather should fix the problems that *lead* to its cluttering, not split it. Oh - sorry, I likely misremembered, and didn't check before writing (I needed to check, obviously). Please ignore the noise in comment 1. Possible solutions: a) always save backups in the source folder Simple to realize, but might contradict with the backup idea b) use a default but allow to change per document Compromise that could be hard to figure/remember since you need to consider all files stored in the past c) do not overwrite existing files by adding some number like "<n>_Untitled_1.bak" For identification where this backup belongs to we could save the original path in the document; however this is a privacy issue and requires a function to restore a document from the backup since we cannot expect users to check the raw files d) don't change and request users to pick unique file names (In reply to Heiko Tietze from comment #3) > Possible solutions: > > a) always save backups in the source folder > Simple to realize, but might contradict with the backup idea > > b) use a default but allow to change per document > Compromise that could be hard to figure/remember since you need to consider > all files stored in the past a+b: use a default (as now) but allow to configure *not per document*, but generally (for all documents) to save in the source folder? (In reply to Heiko Tietze from comment #3) > Possible solutions: > > a) always save backups in the source folder > Simple to realize, but might contradict with the backup idea I don't think there is a contradiction. This 'backup' is actually not a backup in a sense that it doesn't store an up-to-date copy of a document and so cannot be used to protect against data loss. It stores previous version of the document in case one may want to roll back the latest changes. We discussed the topic in the design meeting. Besides documents from one module, eg. Writer, with the same name, the backup files omit the file extension and documents from other modules overwrite each other (test.odt => test.back and test.ods => test.bak). We should keep the extension therefore. MSO does not allow to save files with the same name. And backup copies use some hash number like C:\Users\<user>\appdata\roaming\microsoft\Test((310124753096842400)).asd. See also https://www.ubackup.com/backup-restore/backup-word-documents.html. It's an option to implement a similar solution although hard to figure out for users what file belongs the origin. We could also add a checkbox under Load/Save > General underneath "Always create backup copies" and indented so is clearly related to the backup option (and would be disabled if the parent is off). It could be named "[ ] Use the document's folder instead of backup path" (default is off meaning the backup path is used as today). Alternatively we could ditch the backup folder completely and always save at the document location. And last but not least the solution could be to add the origin somehow to the filename or use sub folders. (In reply to Heiko Tietze from comment #6) > We should keep the extension therefore. That's bug 143038 > We could also add a checkbox "Use the documents folder instead of backup path" That's bug 68565 > Alternatively we could ditch the backup folder completely and always save at > the document location. That is a bad idea. Lots of people have organizational problems and can't handle multiple files with the same name. Plus, now you have backups in your "I need to back this up" folder that will interfere with your real backup program. > And last but not least the solution could be to add the origin somehow to > the filename or use sub folders. As MikeK noted elsewhere, maximum file name length quickly becomes a problem if you try to add the path to the filename. A mirrored subfolder structure is probably the only valid option. (In reply to Justin L from comment #7) > > Alternatively we could ditch the backup folder completely and always save at > > the document location. > That is a bad idea. Lots of people have organizational problems and can't > handle multiple files with the same name. Plus, now you have backups in your > "I need to back this up" folder that will interfere with your real backup > program. Please stop referring to these files as backups. 'Backup' is a misleading name, these files are not actually backups, they are previous versions, so it is perfectly all right if they are backed up, they MUST be backed up. And can you elaborate on those 'organizational problems'? '.bak file in the same folder' is the most common approach, and no one is complaining. Being able to see where the old version is is good, many users are confused by the current approach and don't even know they have a previous version to roll back to - or to delete with other sensitive data when necessary, so it is a security hazard as well. (In reply to Justin L from comment #7) > > We could also add a checkbox "Use the documents folder instead of backup path" > That's bug 68565 Note that *this* is "Please provide a way to save backups in the same folder as the original file at least as an option" - so this is only a dupe of the bug 68565. As such, it is clear why OP is upset, when unrelated ideas are discussed here. (In reply to Mike Kaganski from comment #9) > so this is only a dupe of the bug 68565. A more elaborate solution would be bug 89651. But either way, this is a dup. *** This bug has been marked as a duplicate of bug 68565 *** |