Bug or undesired behavior when quota exceeded

Matt McCutchen matt at mattmccutchen.net
Thu Nov 8 14:05:26 GMT 2007


On Thu, 2007-11-08 at 12:30 +0100, Janusz Jurski wrote:
> I have just noticed an undesired behavior when using rsync when disk 
> quota is exceeded.

> 1) I normally execute two following commands to synchronize folders 
> between a local host and a remote host:
>   rsync -aCPvu --existing <dir1> user at host:<dir2>
>   rsync -aCPvu --existing user at host:<dir2> <dir1>
> 
> 2) Assume that files are in-sync on the hosts. Then we change a file on 
> the local host. When I execute the first rsync command, the file shall 
> be copied to the remote host. When the second command is executed, no 
> copying shall occur as the files are in sync after the first command.
> 
> 3) Unfortunately, it may happen that the disk quota during the first 
> command execution is exceeded.

> 5) When the second command is invoked, rsync starts copying the file 
> from the remote host to the local one. This is an undesired behavior, as 
> the file changed on the local host gets overwritten. This is because the 
> time of the file on the remote host is left in an incorrect state during 
> the first command execution (stopped by the quota limit).
> 
> Any idea on how to avoid such a situation?

The trouble is that you are passing --partial (-P = --partial
--progress), which makes the receiver in the first command move the
partially received copy of the new source file over the old destination
file.  Remove --partial (by replacing -P with --progress) and you should
be fine: the receiver will discard the partially received file, leaving
the old destination file as is, and the second command will skip
transferring it back to the first host because of --update.  For a more
robust solution, you might look into a program that is designed for
two-way synchronization, such as Unison
( http://www.cis.upenn.edu/~bcpierce/unison/ ).

> Or maybe we can correct rsync 
> code to set file time to the correct one in case of disk quota error?

No.  For one thing, this won't solve the problem because rsync checks
size as well as mtime and the sizes will be different.  Also, we want
the source and destination files to appear different so that if the user
gets the disk quota on the second host raised and attempts the first
command again, the new source file will be retransferred.

Matt



More information about the rsync mailing list