<div dir="ltr">
<div>I believe that the changes to support --preallocate and --sparse 
together have broken --preallocate by itself (commit 
f3873b3d88b61167b106e7b9227a20147f8f6197)<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div class="gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-yj6qo gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-ajU"><div id="gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-:1dd" class="gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-ajR"><img class="gmail-m_5721543457868330663gmail-m_-7564285778631331167gmail-ajT gmail-m_5721543457868330663gmail-CToWUd gmail-CToWUd" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div>

<div>in syscall.c in appears maybe there is a logic error (that should be bitwise-OR, not logical-OR):</div><div><br></div><div><br></div><div>OFF_T do_fallocate(int fd, OFF_T offset, OFF_T length)<br>{<br>        int opts = inplace || preallocate_files ? 0 : DO_FALLOC_OPTIONS;</div>

<div><div dir="ltr" class="gmail-m_5721543457868330663gmail_signature"><br></div></div>

<div><br></div><div><br></div><div><br></div></div>