--remove-source-files problem when used with --write-batch

[Ted Toal]

I used this rsync command:

	rsync -az --only-write-batch=tmp.rsync --inplace --remove-source-files --include='*' --include='*/' tmp/ nonexistent_dir

which created file tmp.rsync.sh containing this rsync command:

	rsync --filter=._- -az --read-batch=tmp.rsync --inplace --remove-source-files ${1:-nonexistent_dir} <<'#E#

which when executed gives the error:

	--read-batch cannot be used with --remove-source-files

and furthermore, the source directory, tmp/, still contains its files.  

rsync seems to be incorrectly including --remove-source-files into the rsync.sh file and ignoring it at the sending side.

My rsync is: rsync  version 3.0.6  protocol version 30
My system is: CentOS release 5.7 (Final)

What I wanted to do was try using rsync as an archive tool, like tar/gzip.  Tar/gzip compresses the archive after it is created. I wanted each file in the archive to be compressed before adding it to the archive, and further I wanted the files to be deleted as soon as they were added to the archive, because I'm trying to compress a very large directory in-place on an almost-full device.  It seemed like the above command would do the job, and in fact it does work, except for (lack of) deletion of the sending-side file immediately after it is added to the batch (archive) file.

It would be nice if there were a --remove-source-dirs argument also, to remove directories on the source as well as files.  

I don't know how possible or impossible this might be with rsync as it is currently structured, but it would be nice if the batch file created by --write-batch could be used as the destination device also.  I.e., if I do the command shown above and partway through it fails for some reason (say the system is shut down), it would be great if the batch file were intact and usable with its contents as they are up to that point, and if the rsync command could be restarted and it would use that batch file as the destination, and continue adding to it.  In short, what I want is an rsync where the destination, instead of being a directory tree, is a single file that retains the compressed form of data used by rsync to send it.

ted



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Old saw: 'If it ain't broke, don't fix it'
Toal's corollary: 'If it's broke, fix it'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Ted Toal
ted at tedtoal.net






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20131121/c0634520/attachment.html>