Ubuntu

When moving, renaming, deleting files, their backup copies are not modified

Reported by Alexander Konovalenko on 2007-08-15
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Nautilus
Won't Fix
Wishlist
nautilus (Ubuntu)
Wishlist
Ubuntu Desktop Bugs

Bug Description

Binary package hint: nautilus

When moving, renaming, and deleting files that have backup copies (those have the same filename with a tilde in the end, like 'filename~'), the backup copy is not affected by any such change to the main file. Since the backup copies are usually invisible (they are hidden by default), that leads to counter-intuitive experience, where as many files are moved, renamed, and deleted, they leave hidden traces that contain old information (which is potentially sensitive) and occupy disk space. Those remaining backup files usually have to be cleaned up manually, and some end up hanging around for a long time without being cleaned up.

One way to fix this is to automatically apply the same change (renaming, moving, or deletion) to the backup copy if one exist.

ProblemType: Bug
Architecture: i386
Date: Thu Aug 16 02:30:33 2007
DistroRelease: Ubuntu 7.04
Package: nautilus 1:2.18.1-0ubuntu1
PackageArchitecture: i386
SourcePackage: nautilus
Uname: Linux chronos 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. I don't get it why the backup copies should be renamed if you rename the original i mean thats why they are named "backups" and you should take care of them (deleting mostly). I have a couple of code backups files and i don't really want to deleted if for some mistake i delete the original one. Probably for renaming could work but not sure. Anyways feel free to open a report in the upstream bug database http://bugzilla.gnome.org; thanks.

Changed in nautilus:
assignee: nobody → desktop-bugs
importance: Undecided → Wishlist
status: New → Incomplete
Changed in nautilus:
status: Unknown → Confirmed
Changed in nautilus:
status: Incomplete → Triaged

Whether backup copies should be renamed with their originals depends on the user's intent regarding the renaming. Consider the following use case:

Apollo would like to debug his browser by resetting its configuration. He renames ~/.browser, his browser configuration file, to ~/.browser.old. He doesn't notice that the backup copy remains in ~/.browser~ because backups are hidden in Nautilus. Apollo creates a temporary configuration file ~/.browser and edits it several times using gedit while debugging his browser. When he is finished, he moves the temporary configuration file to Trash and renames ~/.browser.old back to ~/.browser. But when Apollo looks at the backup copy at ~/.browser~, he is surprised. He expected to find the same backup copy of the original file that was there before, but he finds instead the second latest copy of the temporary configuration file saved by gedit.

Another use case about deleting sensitive information:

Venus saved drafts of her love letters to Apollo in her home directory. Now that her hot-tempered husband Vulcan will come back from a journey soon, she destroys the evidence by moving her letters to Trash and emptying the Trash. She is not aware that the backup copies remain, because she did not get any warning about them, and they are hidden by default. Venus also doesn't understand the Unix permission model and her home directory is world-readable. When Vulcan looks there, he will find the disgraceful letters.

Depending on the user's intent, sometimes the backup files should be treated as a single object with their originals, and sometimes not. What bothers me is that currently the user doesn't get to choose, and that leads to failures like those described in the use cases above.

The proper way to fix this from the usability point of view is to put the home directory under a version control system. Until that is widely accepted, a work-around is required. It could be a configuration option to treat the backups and originals as a single object, or it could be a set of warning dialogs that would notify the user that her action was not applied to some backup copies of selected files and ask whether she wants to rename/move/delete the backups as well.

The fix needs a bit more thinking before it can be implemented, but I hope the problem is clear now.

Changed in nautilus:
status: Triaged → New

Sebastian, I accidentally changed reverted the status to New because I didn't notice you change it to Triaged. Please set the status of this bug to Triaged again.

Changed in nautilus:
status: New → Triaged
Endolith (endolith) wrote :

I just realized I have dozens of hidden files on my Desktop because of this bug. :) Please fix it.

Volodya (volodya) wrote :

$ find -name "*~" -delete

I run this ever so often to get rid of all the backup files.

Endolith (endolith) wrote :

How about this? We could consider the backup file to be "attached" to the main file, and both would normally be shown as one icon. If you select the icon, it will say something like this in the status bar:

    "To do list.txt" (and 1 hidden attachment) selected

If you then move or rename this, the backup file gets moved or renamed, too. If you want to work with each file separately, you can open the context menu and click "Expand", and any selected files with attachments will be expanded to show all the actual files, with lines connecting them to show which ones are attached. Or we could use the "Show hidden files" command to expand these into separate files. (Or both.) Then in this mode you can work with each file individually if you need to.

Other possible applications:

This functionality would also be useful for HTML files with folders of content attached. Like in Firefox when you save as "Web Page, complete", you will get a file like "My Homepage.html" and a folder like "My Homepage_files" which contains associated content. In Windows, these are treated as a group in some ways (deleting one deletes both), but not in others (renaming pops up a dialog). This "grouped file" functionality could be used for these, too.

In OS X, extra file data ("resource fork") is stored in ._whatever files. These could be "connected" to the original file, too, so that moving or renaming files in Ubuntu maintains their metadata for later use in OS X.

Other similar things: .info files, "bundles", application directories, ... There are probably other, better uses I'm not thinking of.

Endolith (endolith) wrote :

"Show attachments" would be better wording than "Expand". I was just thinking of the way different IM accounts are grouped as a single user in Pidgin.

Changed in nautilus:
importance: Unknown → Wishlist
Changed in nautilus:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.