snapshot failure on 1.0.2

Check this files/folders: maybe you don't have the right permissions on them.
If you can manage to copy them the it's ok.
If not you can exclude them.
Or (I don't really recommend) you can select "continue on errors" from settings". This way it keeps partial snapshots.

ok, thanks. fixing the permission errors is straightforward.

however, i was curious about why i was getting an "input/output error" on some files. on closer examination, it seems that this does not have to do with permissions, but rather that all the files that throw this error are size 0 (zero). attempting to open/view them results in this kind of error: "File is not readable: ~/.recently-used.xbel.HFEL7U"

unfortunately, not ALL size zero files cause this problem -- and it is not clear from looking at permissions how/why they differ. this seems like something worth investigating for future release of BIT.

in the meantime, is there a way to specify an exclusion pattern of files of size 0?

"File is not readable: .." means you don't have the right to read it !
Run "ls -lh ~/.recently-used.xbel.HFEL7U" to check rights and user/group.

Just to test that it is not about zero size file, create an empty file: "touch ~/abc.txt" and do a backup.

PS: no, for the moment you can't exclude files based on size.

as i mentioned earlier: all the files that choke BIT are zero size -- but there are other files of zero size that do not choke BIT.

however, for ALL the files of zero size, i DO have the right to read those files (and ALL those files have EXACTLY the same permissions, owner, and group).

the ONLY difference that i can detect is that for some peculiar reason, some of them give the "file not readable" error -- and these are the files that BIT chokes on.

This is why you should run "ls -lh <file>" on this files.

sigh. what i wrote above about permissions and owners IS based on "ls -lh <file>".

perhaps showing the results of "ls -lh" on two different files of size zero will clarify:

-rw-r--r-- 1 kabanta kabanta 0 2009-11-07 12:45 .sudo_as_admin_successful

-rw-r--r-- 1 kabanta kabanta 0 2010-09-23 06:36 .openoffice.org/3/user/registry/data/org/openoffice/Office/Common.xcu.bak

BIT chokes on the second but not the first. so, what does the result of running "ls -lh" on these files tell you?

You are right, nothing.
Maybe this files are locked somehow. You can try to copy this strange file manualy or try to find out who lock them.

I'm experiencing the same. Snapshot failure. I don't often encounter failures when upgrading software. I'm unable to use Back In Time now. This is not good.
This software should work. Don't ask me to go in an fix permissions. I didn't have to do it before. Why do I have to do that now? Don't fix the person. Fix the software.

ok. these errors are new since BIT 1.0.2 -- upon examining my earlier snapshots (successful under earlier versions of BIT), i see that the files that are causing the errors now were NOT copied under earlier versions of BIT. this suggests that the implementation of BIT has changed from a default of "continue on error" to "fail on error". if this is true, it is likely that many people will encounter such errors and assume there is a bug in the new version of BIT. you might want to explicitly highlight this in the changelog or documentation.

based on this experience, i also have a feature suggestion: as you point out, setting BIT to "continue on error" is not something we want to do as a standard. however, it would be nice if BIT popped up a message at the end of a snapshot session and said, "the following errors occurred [list]. should BIT continue even with these errors? y/N?" the advantage of this is that a user can quickly scan the errors and decide they are either significant or trivial -- and then choose whether partial or no backup is appropriate for the specific snapshot session.

The problem with BIT < 1.0 is that it ignore all error. BIT >= 1.0 does check for errors and this is the fix.
If you like old behavious just check "Continue on error".

BIT can't ask the user to confirm things because it can be runned from cron ... so no GUI.

I do agree that I should update documentation.

OK, I updated on-line doc:
http://backintime.le-web.org/2010/10/24/snapshot-fails-after-updating-to-back-in-time-1-0/

Hi,
the error occures in my case ALTHOUGH I'm running BiT as root.

This is the output:

========== Take snapshot (profile 1): Fr 21 Jan 2011 15:10:40 ==========

[E] Error: rsync: send_files failed to open "/home/fabian/Xorg.0.log_diff": Input/output error (5)
[E] Error: rsync: send_files failed to open "/home/fabian/.compiz/session/10224a6d5f8c2b0fa7129132198485092100000022680081": Input/output error (5)
[E] Error: rsync: send_files failed to open "/home/fabian/.compiz/session/106fd7c0a44970bd4b129101846065113900000022280081": Input/output error (5)
[E] Error: rsync: send_files failed to open "/home/fabian/.compiz/session/10e343a056a574d4ad128818934119480600000021370079": Input/output error (5)
[E] Error: rsync: send_files failed to open "/home/fabian/.compiz/session/10fea59c3084db7e2c129070752769627300000022120082": Input/output error (5)
[E] Error: rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)
[E] Failed to take snapshot 21.01.2011 15:10:40 !!!

I'll change the behaviour in order to let BiT continue despite the error, but I don't think that the bug is fixed.

Any further suggestions?

Thanks.

About the last Error:

rsync: writefd_unbuffered failed to write 4 bytes to socket [sender]: Broken pipe (32)

The ext. hdd (which is the place where the backup is saved) is an ext3 and not encrypted...

I solved the broken pipe through fsck, I'm still worrying about the Input/output error as I'm running BiT as root and should not get such an errror.. or am I wrong?

Thanks!

Could these input output errors be because the files have changed or been removed by the system between rsync building the file list and actually going to copy the file? I am experiencing them too, mainly on firefox session files:
/home/dougle/.mozilla/firefox/9yolfuit.default/sessionstore-141.js

This can be an explications: files are changed / removed while rsync it taking the snapshot.

You can select "continue on errors" and let BIT ignore errors (like BIT < 1.0) or you can exclude this kind of files / folders.

Regards,
Dan