Description: All backups are saved to a single folder and I found no way to change it - backup path can be modified but still points to new single folder. This creates a number of issues: 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. 2. Many people find it illogical and against the traditional approach when backups are stored in the same folder as the original file. 3. Single folder with all the backups is cluttered and difficult to navigate. Please provide a way to save backups in the same folder as the original file at least as an option. Affects not just the Writer but all the components. Steps to Reproduce: to illustrate point 1 in the description 1. create dir1/file.odt 2. save it 3. modify it 4. save it again 5. create a file dir2/file.odt 6. save it 7. modify it 8. save it again Actual Results: file.odt in the backup folder contains the backup of dir2/file.odt saved at step 6, backup of dir1/file.odt saved at step 2 is lost Expected Results: backups of both dir1/file.odt and dir2/file.odt should've been retained in their respective folders Reproducible: Always User Profile Reset: No Additional Info: Version: 7.3.5.2 / LibreOffice Community Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded
(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 ***