Well, I know already that you cannot do chgrp on a VFAT device, so I ran rsync with --no-o and --no-g, as well as using -rltDv rather than -av, so I think that there should be no chgrp attempts at all.

What is wrong?

I am using rsync 3.0.2 under Slackware 12.1, and the exact call is:
rsync -rltDv --no-o --no-g --delete --modify-window=1 --progress \
-stats /museum/ /mnt/tmp/backup/museum

I also tried without -no-o and -no-g, which should be superfluous. And, yes, I am running as root. And I know that VFAT does not support chgrp, but how do I keep rsync from trying it?

You could try mounting the vfat device using the quiet option, which causes it not to return errors on chown or chmod requests. Do you really need to specify --no-o and --no-g? I thought those were the default options. Have you tried running the command without specifying them?

Well, the quiet option looks like curing the symptom, doesn't it? I mean, rsync should not even attempt to do a chgrp .

In fact, I started with -av, then I used -rltDv (omitting the implied o and g options), finally I added the presumably superfluous --no-o and --no-g . In all cases I got the same effect.

I tried rsyncing a single file onto a vfat device myself, to try and see the behaviour you describe. As in your case, I synced as root, and the device wasn't mounted with quiet. I got the chgrp error when using 'rsync -av', but I didn't get it when using 'rsync -av --no-o --no-g' or 'rsync -rltDv'. It's pretty strange that we get different results, I'm running rsync 2.6.9 on Ubuntu, since you're running a later version it seems unlikely to be a bug unless there's a regression.

Does every file and directory in the tree that you're syncing give the error, or does it just occur on some of them? Maybe that would give some more hints as to where the problem is appearing.

It seems to occur with mixed-case filenames. I have a lot of files of the form [Ff]-12345-tif or TIF. When the F is capital and the tif is lowercase, I seem to get a chgrp message.

An additional and possibly related problem is that the --delete option seems to delete about all files in the directory (it displays them consistently in lowercase) but it stores them (same names, except for the case) in the case they had in the source. And the next time around, it deletes and inserts them all-- again! This problem also seems to be mixed-case-related.

I have probed somewhat further, and I am beginning to suspect that rsync itself is not the culprit, but vfat.

I tried to rename all files in the VFAT system to lowercase with:
for f in *; do
g=`expr "xxx$f" : 'xxx\(.*\)' | tr '[A-Z]' '[a-z]'`
if [ "$f" != "$g" ];
then
TEMP=`tempfile` ;
echo "$f \> $TEMP \> $g"
mv "$f" $TEMP ;
mv $TEMP "$g";
fi
done

In fact, I first tried mv "$f" "$g" without the TEMP variable, and I got messages saying that files F-12345.TIF and f-12345.tif were identical. So I added the temporary name, and a diagnostic echo, and I saw a stream of messages declaring the renaming of all files. However, if I check at the end, all file names are unchanged, lowercase tif has remained lowercase, uppercase is still uppercase, all Fs are still uppercase.

I can imagine that this behavior confuses rsync. I have tried about all options that mount -t vfat is willing to accept-- does anyone have any other suggestions?