I believe that the changes to support --preallocate and --sparse together have broken --preallocate by itself (commit f3873b3d88b61167b106e7b9227a20147f8f6197)
The previous behavior of --preallocate was to do just that: reserve blocks in the filesystem WITHOUT setting the size of the file to the final length. The reported filesize would change as the preallocated blocks were actually written. Unfortunately, the change causes a whole bunch of problems with our automated backup, and in particular with --append-verify or --inplace. The normal sequence we use in our large-file backup system is to combine preallocate with append-verify. When a partially written file is restarted, it no longer goes through proper verification (with append-verify). Worse, if you do only --inplace, then the entire file goes through verification rather than only the previously-transfered portion. I believe this is due to the filesize misrepresenting how much data was actually written. in syscall.c in appears maybe there is a logic error (that should be bitwise-OR, not logical-OR): OFF_T do_fallocate(int fd, OFF_T offset, OFF_T length) { int opts = inplace || preallocate_files ? 0 : DO_FALLOC_OPTIONS;
-- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html