Backup fails with OSError: [Errno 61] No data available (on some video files ?)

[alci63]

Hi,

I am seeing the following error while backing up my home directory (Ubuntu 22.04, rdiff-backup v. 2.0.5):

Processing changed file Vidéos/formation_xrpu_personnalisation_27-09-2021 15:33:43.webm.mov Traceback (most recent call last): File "/usr/bin/rdiff-backup", line 32, in rdiff_backup.Main.error_check_Main(sys.argv[1:]) File "/usr/lib/python3/dist-packages/rdiff_backup/Main.py", line 395, in error_check_Main Main(arglist) File "/usr/lib/python3/dist-packages/rdiff_backup/Main.py", line 417, in Main take_action(rps) File "/usr/lib/python3/dist-packages/rdiff_backup/Main.py", line 353, in take_action Backup(rps[0], rps[1]) File "/usr/lib/python3/dist-packages/rdiff_backup/Main.py", line 442, in Backup backup.Mirror(rpin, rpout) File "/usr/lib/python3/dist-packages/rdiff_backup/backup.py", line 39, in Mirror DestS.patch(dest_rpath, source_diffiter) File "/usr/lib/python3/dist-packages/rdiff_backup/backup.py", line 269, in patch ITR(diff.index, diff) File "/usr/lib/python3/dist-packages/rdiff_backup/rorpiter.py", line 313, in call last_branch.fast_process(*args) File "/usr/lib/python3/dist-packages/rdiff_backup/backup.py", line 587, in fast_process if self.patch_to_temp(mirror_rp, diff_rorp, tf): File "/usr/lib/python3/dist-packages/rdiff_backup/backup.py", line 612, in patch_to_temp result = self.patch_snapshot_to_temp(diff_rorp, new) File "/usr/lib/python3/dist-packages/rdiff_backup/backup.py", line 658, in patch_snapshot_to_temp report = robust.check_common_error(self.error_handler, rpath.copy, File "/usr/lib/python3/dist-packages/rdiff_backup/robust.py", line 35, in check_common_error return function(*args) File "/usr/lib/python3/dist-packages/rdiff_backup/rpath.py", line 148, in copy return copy_reg_file(rpin, rpout, compress) File "/usr/lib/python3/dist-packages/rdiff_backup/rpath.py", line 181, in copy_reg_file return rpout.write_from_fileobj(rpin.open("rb"), compress=compress) File "/usr/lib/python3/dist-packages/rdiff_backup/rpath.py", line 1475, in write_from_fileobj copyfileobj(fp, outfp) File "/usr/lib/python3/dist-packages/rdiff_backup/rpath.py", line 79, in copyfileobj inbuf = inputfp.read(blocksize) File "/usr/lib/python3/dist-packages/rdiff_backup/rpath.py", line 1742, in read return self.file.read(length) File "/usr/lib/python3/dist-packages/rdiff_backup/hash.py", line 43, in read buf = self.fileobj.read(length) OSError: [Errno 61] No data available

The file ~/Vidéos/formation_xrpu_personnalisation_27-09-2021 15:33:43.webm.mov does exist and is readable, it's a legitimate video file. I encountered the same error with other videos files in other directories. Maybe it' not cause by them being videos but rather their size, I don't know.

[ikus060]

Hi @alci63

Could you problem more details about your problem:

1. The full command line you ran to generate the error.
2. The output of the command line with -v 9 to generate verbose output.

Thanks

[ikus060]

According to POSIX error code: Errno 61: ENODATA

ENODATA
              The named attribute does not exist, or the process has no
              access to this attribute; see [xattr(7)](https://man7.org/linux/man-pages/man7/xattr.7.html).

              In POSIX.1-2001 (XSI STREAMS option), this error was
              described as "No message is available on the STREAM head
              read queue".

Strangely, it fail on file.read() instead of getxattr() Could you check if you have any xattr on this file ?

[alci63]

The file does not seem to be any xattr on the file (lsattr reports nothing but dashes).

But there is another point : to simplify my test case, I tried to copy the file to another directory, to backup that directory alone. Doing that, I have an error in cp :

❯ cp Vidéos/formation_xrpu_personnalisation_27-09-2021\ 15:33:43.webm.mov test-rdb/ cp: error reading 'Vid'$'\303\251''os/formation_xrpu_personnalisation_27-09-2021 15:33:43.webm.mov': No data available

So the problem is probably in my FS, and not in rdiff-backup. I'll investigate this and come back with the root cause.

That said, deja-dup just ignored (and reported) the error on the file, and continued the backup. Maybe this would be a better behaviour than to stop the whole backup.

[ericzolf]

That said, deja-dup just ignored (and reported) the error on the file, and continued the backup. Maybe this would be a better behaviour than to stop the whole backup.

We can probably do this now that we know which error code needs to be ignored.

[ericzolf]

I thought a bit more about it, and as you wrote, it might be due to some strangeness of your file system, and this shouldn't be simply be skipped. Other files on the same file system might not show the behaviour but still be corrupt, so failing altogether is IMHO the right decision. What do you think?

[ericzolf]

No reaction, closing. Re-open if necessary.