Bug 11668 - incorrect/inconsistent behavior when --backup-dir is on a full filesystem
Summary: incorrect/inconsistent behavior when --backup-dir is on a full filesystem
Status: RESOLVED FIXED
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-12 01:22 UTC by Andrew Bezella
Modified: 2016-04-17 23:36 UTC (History)
1 user (show)

See Also:


Attachments
Test case for test suite (1.25 KB, patch)
2016-04-01 19:03 UTC, Jim Nelson
no flags Details
Proposed patch (393 bytes, patch)
2016-04-01 19:04 UTC, Jim Nelson
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Bezella 2016-01-12 01:22:01 UTC
hello - we are having some issues w/the exit value of `rsync --backup` when --backup-dir is on a full filesystem.

for instance:
* rsync  version 3.1.2  protocol version 31
* the filesystem mounted on /2 is 100% full, /1 has plenty of space

when the destination files exist but a delta needs to be transmitted, running:
> rsync -av --delete -b --backup-dir=/2/tmp rsync://instance0.us.archive.org/items_11/McGillLibrary-129621-5035 /1/2.1/.
results in:
> receiving incremental file list
> McGillLibrary-129621-5035/129621_scandata.xml
> rsync: backup mkdir /2/tmp/McGillLibrary-129621-5035 failed: No space left on device (28)
> 
> sent 164 bytes  received 1,333 bytes  2,994.00 bytes/sec
> total size is 26,763,596  speedup is 17,878.15
and an exit status of 0 despite the error.  the file-to-be-modified remains unchanged, and the rsync tmpfile that is transferred over is left in place.

subsequent runs of the command also fail, but with an exit value of 23 (i'm guessing because the make_backup reports failing as well as the "backup mkdir"?):
> receiving incremental file list
> rsync: backup mkdir /2/tmp/McGillLibrary-129621-5035 failed: No space left on device (28)
> rsync: delete_file: make_backup(McGillLibrary-129621-5035/.129621_scandata.xml.nKW4Sg) failed: Success (0)
> McGillLibrary-129621-5035/129621_scandata.xml
> rsync: backup mkdir /2/tmp/McGillLibrary-129621-5035 failed: No space left on device (28)
> 
> sent 164 bytes  received 1,333 bytes  2,994.00 bytes/sec
> total size is 26,763,596  speedup is 17,878.15
> rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1650) [generator=3.1.2]

i _believe_ that this behavior started in 3.1.0 (best recollection is that 3.0.9 did not suffer from this, although https://lists.samba.org/archive/rsync/2013-July/028488.html looks like it may be related).

thank you in advance for any help you can provide, and thanks for rsync!  please let me know if there is additional information that may be useful or further tests that can be run.
Comment 1 Jim Nelson 2016-04-01 19:03:13 UTC
I've investigated this problem and coded a patch, which I will attach after posting this comment.  I also coded a test case for the test suite.

Using the test case and git bisect, I determined the problem was introduced in this commit:

commit 21cddef2b460098f5289b9cdbd592bf8f0f9e759
Author: Wayne Davison <wayned@samba.org>
Date:   Sat Jan 3 12:00:02 2009 -0800

    Improved the backup code:
    - Backups do not interfere with an atomic update (when possible).
    - Backing up a file will remove a directory that is in the way
      and visa versa.
    - Unify the backup-dir and non-backup-dir code in backup.c.
    - Improved the backup tests a little bit.

It appears this 2009 patch was excluded from v3.0.9 but included in v3.1.0 and onward, which explains why Andrew didn't see it until the later release.

The test case requires root (to mount a small file-based file system and fill it to capacity).  It uses trap to unmount the fs in case of error and not leave the system in a poor state.

My proposed patch is straightforward: if unable to make the backup, call exit_cleanup(RERR_FILEIO).

I'd very much like to see this bug fixed, so please let me know if there's anything I can do to improve either patch for inclusion.
Comment 2 Jim Nelson 2016-04-01 19:03:51 UTC
Created attachment 11960 [details]
Test case for test suite
Comment 3 Jim Nelson 2016-04-01 19:04:16 UTC
Created attachment 11961 [details]
Proposed patch
Comment 4 Wayne Davison 2016-04-17 23:36:14 UTC
Thanks for the patch and the test case. I haven't included the test in the suite because it's not usually run as root.  Fixed in git: b973bffa949a2407768e4ec8fb501b3fbe932f91.