The snapshot folder should have write access

Bug #423086 reported by Borph
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Back In Time
Fix Released
High
Bart de Koning

Bug Description

If BackInTime runs under more than one user (so more than one profile), the destination folder should not be the same.

Example: BiT as root copies almost whole disk weekly to
/media/extdrive/backintime
and the user 'peter' copies just /home/peter/documents hourly to
/media/extdrive/backintime

then this is a conflict and should be avoided. A solution could be a warning if somebody tries to do this.

Related branches

Changed in backintime:
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Bart de Koning (bratdaking) wrote :

Because the new version actually supports more profiles per user, this bug description is a bit confusing I therefore renamed it. The new multiple profiles per user actually gives a warning when you want to use the same folder more than one time. However that is on a per user basis.
A bug lying on top of the one that is described here, is that you should have write access to the folder that you are trying to use. If backintime is used by more than one user (or root) this check should already circumvent the possibility that multiple users try to use the same folder.

summary: - More than one profile should not point to same destination folder
+ The snapshot folder should have write access
Revision history for this message
Bart de Koning (bratdaking) wrote :

If you do not agree I will off course file this separately and will change the title back again...

Revision history for this message
Bart de Koning (bratdaking) wrote :

A little update: it actually checks this already, however when there is already a backintime folder, it does not check if it has write access to that folder. Making a snapshot then results in an error that the folder new_snapshot could not be created.
So if there is already a backintime folder present you can select that as your snapshot folder without any warnings, although it is incapable of using it.

Changed in backintime:
assignee: nobody → Bart de Koning (bratdaking)
Revision history for this message
Borph (borph) wrote :

Multiple profiles per user? sounds interesting, but is this space efficient? Anyway, with this bug i just wanted to point that the usage of this program should be failsafe, so an unexperienced user does not have an totally unexpected behaviour. Checking write access is an option, but is it enough? I mean I just gave the user the write access to the backintime folder root was saving to, because i just encountered the error to not be able to write there and i assumed the program needs this write access!

Revision history for this message
Richard Bailey (rmjb) wrote :

I don't mean to throw a monkey wrench into this but if there is a multi-user PC that uses BiT then it may be highly likely that everyone who uses that PC will backup to the same space, to the same external hard drive for example.

I don't think that this is an unreasonable use case.

Can we prefix a username to the directory name?

Revision history for this message
Bart de Koning (bratdaking) wrote : Re: [Bug 423086] Re: The snapshot folder should have write access

Could be an idea, then we have to move the ld snapshots though...

2009/10/12 Richard Bailey <email address hidden>

> I don't mean to throw a monkey wrench into this but if there is a multi-
> user PC that uses BiT then it may be highly likely that everyone who
> uses that PC will backup to the same space, to the same external hard
> drive for example.
>
> I don't think that this is an unreasonable use case.
>
> Can we prefix a username to the directory name?
>
> --
> The snapshot folder should have write access
> https://bugs.launchpad.net/bugs/423086
> You received this bug notification because you are a bug assignee.
>

Changed in backintime:
status: Confirmed → Fix Committed
Dan (danleweb)
Changed in backintime:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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