rsync - Feb 2004 - rsync is not copying upper case files

Hi,

I am running rsync on MacOS 10.3 and I want to transfer files to a linux
machine, which has  linux partitions and fat32 partitions.

Transfering the files to the linux partition works without problems,
but if I transfer them to the fat32 partition, files are ignored if all
characters in the file name are UPPER CASE.
- The files which rsync should transfer do not exist in the target
directory. Thus its not a problem with the time resolution of the fat32
system.
- The files do not appear as lower case, they are simply not there at all.
- If a file name contains one lower case character or special character, 
then it is copied without problems.

Many thanks!
Christoph Mayer

On Tue, Feb 03, 2004 at 02:59:02PM +0100, cm@tp4.ruhr-uni-bochum.de
wrote:
> Hi,
> 
> I am running rsync on MacOS 10.3 and I want to transfer files to a linux
> machine, which has  linux partitions and fat32 partitions.
> 
> Transfering the files to the linux partition works without problems,
> but if I transfer them to the fat32 partition, files are ignored if all
> characters in the file name are UPPER CASE.
> - The files which rsync should transfer do not exist in the target
> directory. Thus its not a problem with the time resolution of the fat32
> system.
> - The files do not appear as lower case, they are simply not there at all.
> - If a file name contains one lower case character or special character, 
> then it is copied without problems.
Rsync treats filenames as null terminated, / delemited,
blobs.  It is up to the OS to handle any case or illegal
characters.

This sounds like a FAT32 bug but there may be a mount option
involved.  Eliminate OSX from the problem space and contact
the Linux FAT32 maintainers.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

>> I am running rsync on MacOS 10.3 and I want to transfer files to a
>>  linux
>> machine, which has  linux partitions and fat32 partitions.
>> 
>> Transfering the files to the linux partition works without problems,
>> but if I transfer them to the fat32 partition, files are ignored if all
>> characters in the file name are UPPER CASE.
>> - The files which rsync should transfer do not exist in the target
>> directory. Thus its not a problem with the time resolution of the fat32
>> system.
>> - The files do not appear as lower case, they are simply not there at
>> all.
>> - If a file name contains one lower case character or special
>> character, 
>> then it is copied without problems.
>
> Rsync treats filenames as null terminated, / delemited,
> blobs.  It is up to the OS to handle any case or illegal
> characters.
>
> This sounds like a FAT32 bug but there may be a mount option
> involved.  Eliminate OSX from the problem space and contact
> the Linux FAT32 maintainers.
Hi, I have eliminated OSX from the problem space since the same error
occures from linux to linux. The only difference is that the linux rsync
gives me the (probably unrelated) error message:

failed to set permissions on test-sync : Operation not permitted
failed to set permissions on test-sync : Operation not permitted
rsync error: partial transfer (code 23) at main.c(578)

This error message does not occur when transfering to a linux partition,
but only when transfering to a fat32 partition.

But I could encircle the problem from another side:
The problem only occures if I use the --delete-after option in the
following command:
 rsync -aL --delete --delete-after -e ssh test-sync 
user@machine:/mnt/hda8/backup

If I don't use the --delete-after option, then the files are copied
properly from linux to linux partition and to the fat32 partition.
If I use the --delete-after, then "UPPER CASE file", when transfered
to the fat32 partition are not copied and even deleted, if they already
exist.

So, I think it is due to the fact that an all UPPER CASE file name is
converted to an all lower case file name on the fat32 partition,
which then, since the original file name was different, is instantly
deleted when  --delete-after was chosen.
So my guess is that this could cause the problem.