After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 138440 - when moving file to Trash, move any associated hidden backup files to Trash with it
when moving file to Trash, move any associated hidden backup files to Trash w...
Status: RESOLVED DUPLICATE of bug 311010
Product: nautilus
Classification: Core
Component: Trash
Other Linux
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Reported: 2004-03-29 20:55 UTC by Luke Hutchison
Modified: 2005-07-20 17:19 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

Description Luke Hutchison 2004-03-29 20:55:21 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.
Comment 1 Luke Hutchison 2004-04-22 15:23:06 UTC
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.)

Comment 2 Michael Favia 2004-05-13 21:35:43 UTC
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"
"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.
Comment 3 Luke Hutchison 2004-05-15 00:33:16 UTC
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.

Comment 4 Matthew Gatto 2004-05-15 00:52:18 UTC
changing this to enhancement.
Comment 5 Christian Neumair 2005-07-11 11:44:21 UTC
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?
Comment 6 Luke Hutchison 2005-07-11 13:23:11 UTC
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
  "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... :-)
Comment 7 Stanislav Brabec 2005-07-20 14:27:13 UTC
See more generic bug 311010 on the same: proposal for better handling of
invisible hidden files
Comment 8 Luke Hutchison 2005-07-20 17:19:59 UTC

*** This bug has been marked as a duplicate of 311010 ***