Rsync fails to rename on Windoze2003

Tony Abernethy tony at
Sun Jun 25 16:17:13 GMT 2006

The rename is on the target side, not the source.
If the file is OPEN on the target side, Windows will not let you rename or
otherwise mess with it.
  -----Original Message-----
  From: at
[ at]On Behalf Of Corey
Wirun - personal
  Sent: Sunday, June 25, 2006 10:16 AM
  To: rsync at
  Subject: Re: Rsync fails to rename on Windoze2003

  Thanks Tony,

  The source only has one file:, so my guess is that the short
name business isn't what is biting me here.

    ----- Original Message -----
    From: Tony Abernethy
    To: Corey Wirun - Lists ; rsync at
    Sent: Sunday, 25 June, 2006 07:31
    Subject: RE: Rsync fails to rename on Windoze2003

    This is mostly wild guesses (with luck you get some more knowledgeable
    From what I have observed ...
    file of the form  is an rsync temporary of file
    Trying to rename the temporary file to its permanent name, it ran into
trouble on the name
    The idea is to NOT destroy the older target if the transfer goes south.

    Do a DIR cdrom/riched32/RICHED*.cab   and see if it turns up anything.
    If you have more than one of them, Windows probably gets it wrong as to
    is and which is
    Windows does have a kinda-sorta soft-link with the DOS 8.3 naming.
    Anything complicated in the naming and Windows manages to get it wrong
at least half the time.
      -----Original Message-----
      From: at
[ at]On Behalf Of Corey
Wirun - Lists
      Sent: Saturday, June 24, 2006 11:05 PM
      To: rsync at
      Subject: Re: Rsync fails to rename on Windoze2003

      Some further information:

      I went back to 2.6.6 of rsync on the client and server and at least
the entire sync completes.  I still get the 'Permission Denied' problem on
the rename though.   I had a look at the logs and it appears the rename
error is _always_ on a file name with a '.' as the starting character.  e.g.

      rsync: rename "MEDIA_2006_LATEST/cdrom/riched32/"
(in MEDIA_2006) -> "cdrom/riched32/": Permission denied (13)
      total: matches=278531  tag_hits=1689129  false_alarms=123

      sent 80988322 bytes  received 2116535 bytes  72233.69 bytes/sec
      total size is 1470681718  speedup is 17.70
      rsync error: some files could not be transferred (code 23) at

      My source tree has no files with a '.' at the beginning.  There was a
file '' in the source - don't know why rsync thinks there should
be a '.' in front of it on the destination.

      So it appears that file permissions to not have a bearing on the
problem, but something in rsync is looking for files with a '.' at the
beginning.  But why does this only occur at random, not for every file?
Note the 'false alarms' above - does that mean anything?

      Does anyone have any further notion why I get these rename errors?

      Thanks in Advance!

      ----- Original Message -----
        From: Corey Wirun - Lists
        To: rsync at
        Sent: Saturday, 24 June, 2006 14:22
        Subject: Rsync fails to rename on Windoze2003

        Hi All,

        I've seen several variations on this topic, but nothing exactly the

        I have two Windows 2003 servers that I want to use rsync (2.6.8) to
mirror.  These machines are separated by a WAN.

        Initial attempts to get rsync working between them have not been
successful.  The first rsync went fine, which seeded the files, but the
second sync always fails (at a ramdom time) with a

        rsync: rename "" (in MEDIA_2006) ->
"": Permission denied (13)

        On the server, the rsyncd (from cwRsyncd), I initially ran the
service as user SvcwRsync (from the installer), then added the user to the
Administrators group, then changed the server to run as Administrator, all
to no avail.

        If it was a perms problem, I wouldn't get _any_ files updated, but
this fails on the rename at a random time.

        So I changed the rsync client to --inplace and I see (again random):

        unexpected tag 3 [sender]
        rsync error: error in rsync protocol data stream (code 12) at
io.c(828) [sender=2.6.8]

        I really would prefer to not have to use --inplace to optimize the
bandwidth taken up.

        Any thoughts on why the rename fails?  I would have thought the
owner of the service as local Administrator would be fine!

        Thanks in Advance!


        To unsubscribe or change options:
        Before posting, read:
-------------- next part --------------
HTML attachment scrubbed and removed

More information about the rsync mailing list