Erase backup files external hard drive

Question

I'm looking for a way to delete automatic backup files (those on the form "filename.extension~") from a external hard drive, where I keep a backup from my main disk.

If the files were in /home, I could erase them with bleachbit or a similar program, like ubuntu tweak.

Is it possible to do?

Answer 1

Here's a command-line way of doing this using find. It's a little bit more advanced than using a GUI like Ubuntu Tweak, though.

1. Find the mount point of your external hard drive. Several ways exist:

   • In your file manager, press Ctrl+L to get a text-based location bar. Copy this absolute location to your clipboard.

   • In a terminal identify the hard drive using cat /proc/mounts and locate the mount point. Example:

     /dev/sdc1 /media/1589-880A vfat rw,nosuid,[...]
     

     Indicates the mount point as /media/1589-880A.

2. Open a terminal and use the following find command to list the files matching the search we're performing. Replace the /media path here with the mount point you just found in the previous step. I've added -type f to filter for files only - disregarding links and directories.

   find /media/1589-880A -name "*~" -type f
   

3. If you feel happy about the results and you are sure you want to delete these files, then perform the delete like this:

   find /media/1589-880A -name "*~" -type f -delete
   

   Note: These files will not be sent to the Trash! They go to oblivion straight away. No easy undo exists. Don't ask for undoing this.

Feel free to modify the *~ pattern to allow other matches for other use cases (e.g. *.bak, autobackup-2012-*.tar.gz, etc. It's just using plain shell globbing. It's also perfectly possible to select a sub folder or even a parent folder instead of the mount point. Anyway, always list first before deleting!

Optionally add -xdev to the find command to prevent it descending into other file systems if you're unsure about it.

Answer 2

At a command line prompt in a shell, you can use a command like

rm -i *~

to delete from the current directory those files whose names end in ~. The -i flag tells rm (the “remove” command) to inquire before deleting. If you are not familiar with using shell commands, keep the -i flag in there until you are familiar, because minor errors like a space in the wrong place can have major consequences.

To list the files that will be affected in the current directory, you can say any of the following.

ls *~
ls -l *~
ls -la *~

To make a particular directory be the current working directory, use the cd command and the name of the directory. For example, if you deduce that your backup disk is mounted at /media/xyz (either via the cat /proc/mounts command mentioned in another answer, or more directly via command mount with no parameters, or via df) you would say cd /media/xyz to make the top level directory of the backup drive the current working directory.

Edit: The rm -i *~ command affects files only in the current directory, and does not affect subdirectories. To treat indefinite levels of directories, use the find approach given in another answer. However, if you know how deeply directories are nested, and the level is shallow, you might use a command like

rm -i  *~  */*~  */*/*~

which as shown would delete ~ files in the current directory, its direct subdirectories, and their direct subdirectories.

Edit 2: As gertvdijk mentions in a comment, the clumsy rm shown in previous edit can be streamlined by using ** Bash 4.0+ recursive shell globbing (1). After the command shopt -s globstar has been entered, free-standing instances of ** will glob recursively, ie will stand for all names in current directory and its descendants. (shopt -u globstar turns globstar off, but since one is unlikely to type ** by mistake it seems reasonable to leave it turned on in interactive shells.) Thus, after shopt -s globstar, the command rm -i **/*~ will remove ~ files in current directory and its descendants. Note that if such filenames add up to more than a few million characters, the command line may become too long for bash to handle. The find approach does not have that particular limitation.