rsync - Oct 2006 - "text file busy" on cifs-mounted dir *doesn't* cause rsync error!

Hi there

I am running rsync-2.6.9rc2 and am having difficulty getting rsync to
report an error when I think it should

I mounted (via "mount -t cifs") a remote Win2K3 server and on a XP
client opened a Word document. Then from Linux (FC5) I attempted a

bash$ cp /tmp/other.txt file.doc
cp: cannot create regular file `file.doc': Text file busy

That makes sense - CIFS has the file locked.

Then I tried copying the same file via rsync

bash$ rsync /tmp/other.txt file.doc
bash$ echo $?
0

i.e. rsync says it worked! However it didn't. I ended up with a full
copy of other.txt as .file.doc.3s1d3w - but the final rename on top of
the original file failed.

Rsync didn't return an error. It should?

Help? Is this a bug with rsync, or with Samba (perhaps it returned OK on
the rename when it shouldn't have?)

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

On Thu, Oct 19, 2006 at 03:28:56PM +1300, Jason Haar
wrote:
> bash$ rsync /tmp/other.txt file.doc
> bash$ echo $?
> 0
Re-run the same command under strace:

  strace rsync -av /tmp/other.txt file.doc

That will show you the rename() call that rsync is making and what the
return value is.  If it is 0, there's nothing that rsync can do about
this.  If it is -1 with errno=ETXTBSY, rsync will try to unlink the
destination file.  If that returns -1 w/ETXTBSY, rsync will try to move
the destination file out of the way (you should run with at least 1
level of verbosity have rsync tell you when it does that).  If that
fails, the transfer should fail.

So, you should be able to see exactly what system calls rsync is trying
and what the system is returning via the strace output.  Let me know if
something looks amiss.  From your description of what filename gets
left, it does sound like something went wrong, but I'd guess that it
was the rename() not returning a failure.

..wayne..

Hi there

I just reported a problem to the rsync list, and a minute later realised
a further test I should have tried first.

Basically it appears that "mount -t cifs" SMB shares under Linux
don't
properly report low-level rename failures.

i.e. if I use rsync to overwrite a locked file  rsync think it succeeds
as it:

a: copies file to new temp file
b: renames temp file over existing file.

As the file is locked, b: should fail - but mount.cifs reports it as
working! A further "ls -l" shows the file hasn't been overwritten.

Is this a Samba bug - or a Windows one? If the latter, how are other
rsync users working around this problem of trying to replicate data onto
remote CIFS shares?

This is Samba-2.0.23c under FC5


Jason

---- original message to rsync list -------------

I am running rsync-2.6.9rc2 and am having difficulty getting rsync to
report an error when I think it should

I mounted (via "mount -t cifs") a remote Win2K3 server and on a XP
client opened a Word document. Then from Linux (FC5) I attempted a

bash$ cp /tmp/other.txt file.doc
cp: cannot create regular file `file.doc': Text file busy

That makes sense - CIFS has the file locked.

Then I tried copying the same file via rsync

bash$ rsync /tmp/other.txt file.doc
bash$ echo $?
0

i.e. rsync says it worked! However it didn't. I ended up with a full
copy of other.txt as .file.doc.3s1d3w - but the final rename on top of
the original file failed.

Rsync didn't return an error. It should?

Help? Is this a bug with rsync, or with Samba (perhaps it returned OK on
the rename when it shouldn't have?)

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1