Description: When you check the option to save backup copies of a file, remove the original extension and put .BAK. When recovering the file, it would be easier to know what type of file it was simply by reading the name, even for novice users. Actual Results: TEST.ODS -> TEST.BAK Expected Results: TEST.ODS -> TEST_ods.BAK Reproducible: Always User Profile Reset: No Additional Info: For example, a spreadsheet called TEST.ODS, when making the copy it would be called TEST.BAK but it could well not remember or not know if it was ODS, XLS or any other. Ideally, TEST.ODS should be saved as TEST_ods.BAK and it would be very easy for anyone to recover. Also, if you use it together with the version control of Google Drive (it adds a number in front of the name), it is very easy to drag the read-only BAK to the desktop, rename it and check its content.
It is reasonable, and has a much more important feature to prevent unwanted rewrite of a backup when several files in a single directory share the same name, and differ only by extension (my_project.ODF, my_project.ODS) - but thus has a potential of exceeding the filename length limitation (e.g., file name is near the limit, and four more characters exceed the limit). However, we already create longer names for lockfiles - so no idea how important the possible length limit problem is. We always may simply fallback to the old naming. By the way, I's prefer "TEST.ODS.BAK", not "TEST_ods.BAK".
TEST_ods.BAK or TEST.ODS.BAK seems fine to me, if the second does not give problems, it will always be easier to edit. Regarding the limit of the name ... imagine that with locks included it is 200 characters ... If the filename + extension is more than 200 characters, then the extension is not added to the .BAK. The job of optimizing the length of the name should be done by the user :-)
I agree with the suggestion being made however I would like the naming scheme to be of the form WhateverFilename.odt.bak (and so forth). Using this type of naming scheme also gets around a potential problem with the naming of .bak files as it stands at the moment: Suppose a user has two documents BalanceSheet.odt and BalanceSheet.ods. And the user modifies them at different points in time. What happens with the backups? Well, there will only be one backup (BalanceSheet.bak) file and it will be whichever of those two documents was last modified and saved — the save overwrites the previous .bak file (and in doing so changes the file-type too, if you see what I mean). That's a problem with the current naming scheme for backups. The naming scheme I would like to see gets around this potential issue. I do think that adopting this naming scheme would be of good benefit to LibreOffice — it clarifies things for the user and it solves a potential problem with the naming scheme as it stands at the moment.
*** Bug 119353 has been marked as a duplicate of this bug. ***
"On AIX, Solaris, and Mac: The maximum number of characters for a file name is 255. The maximum combined length of the file name and path name is 1024 characters. The Unicode representation of a character can occupy several bytes, so the maximum number of characters that a file name might contain can vary." Linux can generally do more than that for the path, and so can Windows, but 255 bytes for the filename seems to be pretty much of a standard. FAT32 can only be 8.3 (unless it allows VFAT). Generally, the OS seems to be the limiting factor for max filename length, not the file system. But we shouldn't have to worry about that because INetURLObject should be taking care of that, since we are calling INetURLObject.setExtension(u"bak"). If it is a problem, then INetURLObject needs to be fixed. https://gerrit.libreoffice.org/c/core/+/154407
(In reply to Mike Kaganski from comment #1) > However, we already create longer names for lockfiles - so no idea how > important the possible length limit problem is. Currently LO can't even open a file that has more than 243 bytes long - because it complains about not being able to create the lock file - so that makes adding 4 characters no problem at all.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b6f3129569c22d9d139ca712dcf0db6dc2041565 tdf#143038: preserve extension on backup file It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/d22a6842cf2e6b7763c52ba5121fc76c916fe7b5 tdf#143038: preserve extension on backup file It will be available in 7.6.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.