work around works for me as well
maybe this should be in the help
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back In Time:
Many thanks Dan. BIT is great. At least the workaround of keeping the
/ and /home in different profiles works for me, hopefully for others.
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back
** Changed in: backintime
Status: Fix Committed => Won't Fix
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back In Tim
I did some tests with Sidux. Indeed the latest update is 3.0.7.
It seems that the problem is related to rsync.
On my system with 3.0.6 the bug is there but using "--delete-before" as
workaround works for me. On the other hand --delete-before is slower and use
more memory because it does not use i
Since the problem came from rsync I'll pass it to won't fix.
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back In Time: Fix
Latest Sidux which is based on Debian Sid and KDE 4.3.4. When I load up
synaptic and check rsync this is the version number that shows.
Dan wrote:
> Hi cliff6056,
>
> How did you get 3.0.7 ?
> What distribution are you using ?
>
>
--
Deleted Files are stored in snapshots forever
https://bugs.l
Hi cliff6056,
How did you get 3.0.7 ?
What distribution are you using ?
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back I
Rsync version here is 3.0.7-2.
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back In Time: Fix Committed
Bug description:
Th
It looks like /etc to be a problem. On my side the old version (before
beta16) didn't work, but now it works with both files from /home/user
and from /etc.
I have rsync: 3.0.6
What I did notice is that as a regular user rsync can't explore all
items in /etc.
--
Deleted Files are stored in snaps
Tried the same test with 3 folders in one profile, with one folder being
the /etc, and this time (checked twice) nothing was deleted from any.
Unless I made a mistake in my previous test with 15, I thought the /etc
would at least delete, but definitely not now.
Once I removed the /etc from the in
Using one profile and several backup folders:
Just to report before I go to beta 16 as I just finished testing, I
found that (using a smaller backup /home/me/Documents/FOO and /etc, it
made no difference which order they were in. The home folder always
retained the FOO, but the etc/BOO file would
I think I found the problem. In some cases rsync with "--delete" option
does see some files, but with "--delete-before" it does.
Please try beta16 version from testing repository.
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notifi
Hi cliff6056,
Just to be sure that I have it right:
1. Old mode: one profile with both /home/me and /etc.
Some files are not deleted from new snapshots even they don't exists anymore.
The files with problems are located in /home/me or /etc or both ?
2. New mode: one profile with /home/me and ano
all snapshots have read permissions only, no write permission. in the
original folder (/home/...) i have permission to write
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, wh
Please check user/group/rights:
1. of the original file (before delete)
2. of the file in the correct snapshot
3. of the file in the snapshot where it shouldn't be
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because yo
I found that when I was backing up both /home/me and /etc in the main
profile, that the files were not being deleted from my backups. I have
since then created another profile for the /etc, and have /home/me by
itself in the "Main Profile". Since doing this files are deleted, at
least from the /h
still present in beta15
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back In Time: Fix Committed
Bug description:
The class
still present in beta11. didn't recreate everything though, just
updated.
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back
the output of that command does NOT contain any lines for the files i
deleted.
is there anything else i can do to help you?
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, wh
Hi Dan. The experiences on my system (which I reloaded this morning to
make sure everything was okay) are:
cl...@siduxbox:~$ rsync -aEHAX --delete-excluded -v --chmod=Da+w --delete
--exclude="/media/disk1part4" --exclude="/home/cliff/.local/share/backintime"
--include="/home/cliff/" --includ
You should run the command:
rsync -aEHAX --delete-excluded -i --dry-run --chmod=Da+w --delete
--exclude="/media/Extern/Backups"
--exclude="/home/philipp/.local/share/backintime"
--include="/home/philipp/" --include="/home/"
--include="/media/Data/Fotos/" --include="/media/Data/"
--include="/media/
i thought i'd mention that for me it happens on a fresh install and a
fresh backupfolder.
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Today I created a new test profile and backed up just a couple of
folders to play with. I found that this new profile worked fine,
deleting files from the new snapshots as I believe is expected. My main
backup, however, which has snapshots that were created before I did a
fresh install of backin
WARNING: Command "rsync -aEHAX --delete-excluded -i --dry-run --chmod=Da+w
--delete --exclude="/media/Extern/Backups"
--exclude="/home/philipp/.local/share/backintime" --include="/home/philipp/"
--include="/home/" --include="/media/Data/Fotos/" --include="/media/Data/"
--include="/media/" --
Experiencing the same as Fifoxtasy also using beta10 on kde4 and new
config file. After running backintime -b the line I think that you
request from the output gives a Warning instead of Info and looks as
follows:
WARNING: Command "rsync -aEHAX --delet
Strange, I just tested and it works for me.
If you have the time please do this:
1. create a 'foo' file in one of your included directories
2. take a snapshot (and check that the new file is in the snapshot)
3. remove 'foo' file
4. run 'backintime -b" from command line (and check the new snapshot s
just tried again with the newest version 0.9.99beta10 on kde4. files still
don't get deleted :( in newer snapshots.
ghost files persist
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
T
Just test it and it seems to work. So no longer schedule per included
directory. Use profiles instead.
** Changed in: backintime
Status: In Progress => Fix Committed
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification
I've been following along with this bug since it's been a little bit of
a headache and just found that if I used the solution posted above (i.e.
exclude *.gvfs) and run it from "Back in Time (root)" it works as
expected. The "foo" file vanishes. If I use the same settings and just
use "Back in Ti
Since we removed the Schedule per Included folder option, I added the
--delete-excluded again. This should solve the ghost folders, however I
need to verify that still
** Changed in: backintime
Status: Confirmed => In Progress
--
Deleted Files are stored in snapshots forever
https://bugs.
** Changed in: backintime
Assignee: (unassigned) => Bart de Koning (bratdaking)
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Stat
I know it could be solved by adding the --delete-excluded, however than we
need to redesign the schedule per included folder. It should then hardlink
to snapshots from the same schedule. On hardlinking capable partitions this
issue does not consume more space and it does not take really longer to
a
** Changed in: backintime
Importance: Undecided => High
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back In Time: Confir
I confirm, the bug is valid. Your procedure prove it.
rsync has the option " --delete-excluded" to remove excluded files. This can
fix the bug but it can disable schedule per include directory (or it need to be
redesigned).
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad
Well these are the best bugs off course: ghost bugs that just fix themselves
But this bug is still valid as I found a way to create ghost files in your
snapshots as I described above...
However if your problem reoccurs, please notify us again!
2009/11/12 Andreas
> After having tried to analyse
After having tried to analyse the bug an several backups (unfortunately
they took 2-3h each), I ended up that the bug completely disappeared.
Please don't ask me why...
I uninstalled backintime, deleted all configs, deleted the backups from
the NFS drive, reinstalled backintime, didn't put ".gvfs"
Hey this bug is turning into two:
- the .gvfs problem -> lets continue that one in the default excluded folders
bug
https://bugs.launchpad.net/backintime/+bug/422132
- the problem of removing an included folder what leads to rudimentary ghost
folders in the snapshots
Excluding ".gvfs" actually resolved the issue for me.
Before BiT I had rolled my own similar back up routine using hard links
and rsync and had run into this exact same behavior. What I had
discovered then was that rsync was bombing out on .gvfs (permission
errors) before it finished running and b
The exact commands are logged in your messages log (Command "..." returns 0)
Between " " is the command that is issued (it might be better to have a look
in the syslog, as in messages the commands can be truncated.
You can also run it from the command line: backintime -b than all the
messages are a
39 matches
Mail list logo
