GNOME Bugzilla – Bug 138440
when moving file to Trash, move any associated hidden backup files to Trash with it
Last modified: 2005-07-20 17:19:59 UTC
When a file "myfile" is moved to the Trash, the associated hidden backup file "myfile~" should be moved to the Trash too, if hidden files are not currently being shown. (If they are being shown, there is probably no need to do this.) "myfile.bak" would be a good candidate too, except that it's not actually hidden in Nautilus currently. The problem is that with backup files hidden, when you move a file to the trash, if there is an associated backup file, it stays in the original location. This is: -- Annoying, because you don't realize you have all sorts of backup file junk in your directories until you drop to the commandline. -- A potential security hazard (similar to MS Word leaving invisible edit trails behind) Also, maybe hidden files should always be shown in the Trash, so you know what's really in there.
Actually, this is also a very important consideration when moving files -- the backup files should move too. Whether backup files should be moved or not when *copying* is a different matter. It is probably less of a security hazard if backup files are *not* copied too. (Similar to the situation where lots of grizly details have recently been exposed in various corporate documents, when MS Word has been used to edit them with "track changes" enabled, but with changes being hidden.)
I think the bit about the hidden files in the trash is a moot point. If you follow the flow detailed above the only hidden files in the trash will either be put there by deleting a "real" file, deleting it directly, or deleting a folder containing one. The shadow file deleted automatically when the "real" file is deleted should be expunged with the "real" file when it is removed from trash. The "hidden" file in the "real" folder is taken care of when the "real" folder is deleted. And the regular "hidden" file that was individually deleted (hidden files pref on) should show up in the trash when the user navigates to it with the hidden files still on. Regardless i think that a status bar msg displaying the number of "real" and "hidden" objects in any given folder would be very welcome. Im thinking something like email inbox notation: "15 of 30 total files" or "15 displayed and 15 hidden files" This way the user makes an informed decision before doing anything in a directory (deleting, renaming, etc) with hidden files in it.
I'm not quite sure what you mean about it being a "moot point". I think it is important that when a file is moved to trash, its hidden counterpart be moved too. Certainly it could be good to extend the file indicator to show the number of hidden files. But -- then again, they are hidden for a reason, usually -- and it seems to me that keeping them out of sight always (unless you choose to show them) would be more in line with the current GNOME philosophy of K.I.S.S.
changing this to enhancement.
Any ideas what we should do if the backup file which is to be moved to the trash is already contained in the target location? Is there any common duplicate naming pattern for backup files?
My guess is that you would just call the same code that handles duplicate naming for regular files, and renames them (copy 2) etc. However, it is then possible that your regular file (copy 1) is associated with backup file (copy 3) or something, which is not ideal if the files with the same name don't even have related contents. e.g. if in the following, "->" represents "rename during move to Trash", and "+" indicates multiple files being trashed simultaneously, and each line represents subsequent trash operations: "file~" -> "file~" + "file~" "file~" -> "file~ (copy 2)" [or does it call it "file (copy2)~"?] "file" + "file~" -> "file" + "file~ (copy 3)~" When a backup file is moved to Trash, you could rename any backups that don't have corresponding non-backups that are being moved to Trash with something like "(backup)"..: "file" + "file~" -> "file" + "file~" "file~" -> "file (backup)~" "file~" -> "file (backup) (copy 2)~" "file" + "file~" -> "file (copy 2)" + "file (copy 2)~" "file~" -> "file (backup) (copy 3)~" A simpler alternative is to simply skip numbers that have already been allocated for either a file or its backup, taking the max of each when any of "file", "file~" or "file" + "file~" are written: "file" + "file~" -> "file" + "file~" "file~" -> "file (copy 2)~" "file~" -> "file (copy 3)~" "file" + "file~" -> "file (copy 4)" + "file (copy 4)~" "file" -> "file (copy 5)" "file~" -> "file (copy 6)~" This could probably be accomplished by just revising the current duplicate-file handling code slightly. You'd have to check "file", "file~" and "file.bak" (any others?) for copy numbers. It would also be good to make all hidden files in the Trash non-hidden, so if you go hunting for a file you've lost, then you know it's in there without having to show hidden files. Again, this could be a security consideration for some people too, so they know that when they've deleted a file from the Trash it's gone. Currently I don't think that "(copy n)" is inserted before "~" anyway, so it may make hidden files appear non-hidden in the case of multiple backups being written (although it probably correctly inserts before ".bak"). I have "orphaned" backup files all over my homedir hierarchy now... :-)
See more generic bug 311010 on the same: proposal for better handling of invisible hidden files
*** This bug has been marked as a duplicate of 311010 ***