Re: preallocate working incorrectly in 3.1.3

2019-01-16 Thread TR Reardon via rsync
Just for clarity: the intention is still a logical-OR rather than bitwise-OR? If it's a new file on receiver, 'inplace' would still be set and this KEEP_SIZE would be lost? On Tue, Jan 15, 2019 at 12:06 PM Wayne Davison wrote: > > On Mon, Jan 14, 2019 at 6:11 PM TR Reardon via rsync > wrote:

Re: preallocate working incorrectly in 3.1.3

2019-01-15 Thread Wayne Davison via rsync
On Mon, Jan 14, 2019 at 6:11 PM TR Reardon via rsync wrote: > I believe that the changes to support --preallocate and --sparse together > have broken --preallocate by itself (commit > f3873b3d88b61167b106e7b9227a20147f8f6197) > Indeed, those "opts" values were reversed, and thus fallocate

preallocate working incorrectly in 3.1.3

2019-01-14 Thread TR Reardon via rsync
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