https://bugzilla.samba.org/show_bug.cgi?id=5520


wayned@samba.org changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED




------- Comment #1 from wayned@samba.org 2008-06-14 13:13 CST -------
I assume that the -EPERM error is at the kernel level, and the application gets
a return of -1 with errno = EPERM. It would be much better to return errno =
EINVAL so that the error could be easily distinguished from a real EPERM error
where the user doesn't have permission to operate on the file. Since the
kernel call is complaining about being unable to support the requested
permissions, EINVAL seems like a much more logical error to me. But let's
leave that aside for now.

I assume it is the fchmod() function that is returning the error (sadly, the
strace in the original bug report did not contain the process that was actually
failing). If so, you can avoid the mkstemp failure by not asking rsync to
preserve permissions (e.g. --no-p).

So, is the issue that rsync is trying to create a mode 0600 file and the mount
options are set to make the mount world-readable/writable? I'd be loath to
make rsync retry the fchmod() call with 0666 unless the user asked for that
explicitly. Or perhaps have an option to just skip the fchmod() on the temp
file?

Any no-option ideas that are safe? Perhaps test if the new temp file has bits
set outside the umask, and if so, skip the fchmod()?

You might also try changing your mount options to mount the media as a single
user, which I would imagine would make a mode of 0600 acceptable to the kernel.


--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

https://bugzilla.samba.org/show_bug.cgi?id=5520





------- Comment #2 from piskozub@iopan.gda.pl 2008-06-14 16:26 CST -------
Changing the mount options and/or rsyncing as root did not help in my original
tests. But I probably missed a thing with the options reporting they do not
affect the problem (see below).

I did more tests today under the newest Fedora 9 kernel
(kernel-2.6.25.6-55.fc9).
You are right about the options. This happens only with -p (or -a which is
probably why I missed it before). I actually could successfully sync the vfat
partition replacing -a with -rt (because I did not need the other components of
-a on a FAT partition, anyway).

This means there is a simple workaround but still either rsync or the kernel
should be MHO modified to avoid the -p problem.


--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html