Add option to abort backup if destination directory does not exist

Bug #346285 reported by rvdavid on 2009-03-21
Affects Status Importance Assigned to Milestone
Fix Released
Jean-Peer Lorenz
Fix Released
Jean-Peer Lorenz

Bug Description

Hi there,

As requested from:, I'm opening a bug(wishlist).

Please add the option to "abort backup if destination directory does not exist".

Thank you in advance. :)

rvdavid (rvdavid) on 2009-03-21
description: updated
description: updated
Changed in nssbackup:
importance: Undecided → Wishlist
milestone: none → release0.3
Jean-Peer Lorenz (peer.loz) wrote :

A comment about the current implementation: the current behaviour is, that the destination directory is not created recursivly. Nevertheless, the 'last' specified directory is created. This prevents to backup to an external disk that is not mounted. HTH

A question: the option should be added to the Gui, right?


er... my system is backing up RIGHT NOW to a disk that isn't mounted! NSSBackup has created the directory and is cheerfully filling it with a new full backup. (Ubuntu 9.04)

Because the automount feature of Ubuntu creates a directory for a mounted drive in the form /media/<volume_name>, and removes it when the disk is unmounted, NSSBackup is going to create the 'last' directory specified every time, if I'm reading you correctly, Jean-Peer.

Comparisons being odious and all, Simple Backup does have this option...

rvdavid (rvdavid) wrote :

I was halfway through typing up a reply earlier today, but couldn't word it right as I was distracted - basically, I was going to say what prismatic said regarding ubuntu automounting external usb.

while sbackup had this option, it did not work properly as the gui which should have set the config value in the etc/sbackup.conf was not doing so it was as if it defaulted to 0, because even if you manually edited the file and then changed something in gui, it would revert back.

I've written a more complete post (rant) regarding this behaviour - granted it's on sbackup, but related to the current nssbackup behaviour -

Jean-Peer Lorenz (peer.loz) wrote :

Yes, prismatic7, you're right under certain circumstances. I've tested the issue more extensivly and experienced the following:

* I set the destination to a directory on an external disk (here /media/transfer/backups), where `transfer` is the volume label
* creation of backups as normal user and superuser works as expected
* after unmounting the external disk and invoking of NSsbackup, no backup is created and an error message is displayed (holds for normal users and superusers)

I think, this is the expected behaviour, isn't it?

* If I set the destination directly to the external disk (here /media/transfer), where `transfer` is the volume label
* creation of backups as normal user and superuser works as expected
* after unmounting the external disk and invoking of NSsbackup, no backup is created and an error message is displayed if the application is executed as normal user
* if NSsbackup is executed as superuser, a directory /media/transfer is created and used

This should not happen :-( This bug is confirmed.

Why does this happen? This behaviour occurs in the case (that was not expected) the backup directory is set to the root directory of an external disk. If the user specifies a directory on the disk for the backups, everything works as it should work. (BTW: I've never thought that someone would set the whole disk (i.e. the root directory of the disk) as backup target.)

Despite, the `right` behaviour needs to be defined:
1. the destination directory should be created (not recursivly, i.e. only the last directory in the directory tree) and an additional option is added
2. the destination directory should never be created and the backup is aborted and an error message is displayed, in the case that the specified directory does not exist.

In case 1) an option would be reasonable but not helpful for unexperienced users. It makes NSsbackup more complicated and the possibility of writing into the /media directory still exists.

In case 2) an additional option wouldn't be neccessary since aborting the backup would be the default behaviour.

My suggestion: The default behaviour should be as follows (case 2):
* When defining a backup profile, the backup target must be set to an existing directory.
* If this directory does not exist (when creating a backup) the process is aborted and the user gets informed.

This is the most straightforward solution (in my opinion) without additional GUI elements and easy to implement.

@prismatic7: please explain `Comparisons being odious and all, Simple Backup does have this option...` I don't understand.

Thank you for using NSsbackup and taking the time for reporting bugs.

Best regards. Jean-Peer

Jean-Peer Lorenz (peer.loz) wrote :

A bugfix should be included to 0.2 series.

Changed in nssbackup:
importance: Wishlist → Medium
milestone: release0.3 → release0.2
status: New → Confirmed
Jean-Peer Lorenz (peer.loz) wrote :

I've change the default behaviour from creating the 'last' directory to creating NO directory. By default the backup is aborted now if destination directory does not exist. This prevents accidents like described here and serves the request for an option to enable such behaviour.

Changed in nssbackup:
assignee: nobody → peer.loz
status: Confirmed → Fix Committed

@Jean-Peer. Apologies - my 'Comparisons being odious' comment was lighthearted, referring to Shakespeare's 'Comparisons are odious' line from a play that I can't recall right now (how embarrassing!) The implication is that to compare one (person) to another is impolite.

In any case, Simple Backup Suite (which NSSBackup is based on, yes?) does have an option in its GUI to abort if the destination directory is missing, as @rvdavid notes.

I apologise for any confusion!

Dan Lea (danlea) wrote :

Incidentally, the fix for the sbackup GUI issue is simply to correct the typos in lines 1013-1014 of (/usr/share/sbackup/) replace both occurrences of ‘on_stop_if_not_target_checkbox_toggled’ to ‘on_stop_if_no_target_checkbox_toggled’.

Changed in nssbackup:
milestone: release0.2 → 0.2rc8
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers