Bug 5104 - network copy issues involving filenames ending with a period
network copy issues involving filenames ending with a period
Status: RESOLVED WORKSFORME
Product: rsync
Classification: Unclassified
Component: core
2.6.9
Other Other
: P3 normal
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-25 00:31 UTC by Jason Westervelt
Modified: 2008-01-12 11:54 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jason Westervelt 2007-11-25 00:31:25 UTC
I have two macintoshes, one running 10.4 and the other running 10.5.  I have tested both the stock rsync 2.6.3 and the 2.6.9 versions from macports.  The problem is easily reproduced by trying to sync a directory which has a name ending in a period.  Performing a local rsync (same machine) results in no problems.  However when attempting to rsync from either mac to my linux server (running rsync 2.6.9) the file names get changed.  If, for instance, a directory is named TEST_1.   and it is rsyncd over the network, the resulting filename created on the linux server becomes something like TBI9NE~4  

The problem only happens when the file is being created on the linux server (running gentoo 2007.0).  When the file correctly renamed and sent back to the macs, all is well.

If the file ending in a period is a file, rather than a directory, it is simply not copied.  No existence detected on the server.

I have searched the bugs here as well as on google and have not found anything resembling this issue.  Is this possibly a bug with rsync, or is it simply a matter of neglecting the proper command line options.  I was syncing with   
rsync -av source user@destinationhost/directory
Comment 1 Wayne Davison 2008-01-12 11:54:34 UTC
Rsync doesn't care about filenames, but some filesystem may treat a trailing period as a lack of a filetype and not a significant character (old FAT filesystems were like that).  The destination filename cited looks like such a munged filename, perhaps on a samba filesystem.