Bug 449080 - Rsync cannot copy to a vfat partition on kernel 2.6.25 with -p or -a options
Summary: Rsync cannot copy to a vfat partition on kernel 2.6.25 with -p or -a options
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 9
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-30 10:24 UTC by Jacek Piskozub
Modified: 2008-07-04 03:40 UTC (History)
1 user (show)

Fixed In Version: 2.6.25.9-76.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-07-02 06:34:53 UTC
Type: ---


Attachments (Terms of Use)
Strace of the failed rsync (14.09 KB, text/plain)
2008-05-30 16:59 UTC, Jacek Piskozub
no flags Details
Strace of the successful rsync under kernel 2.6.24 (13.17 KB, text/plain)
2008-05-30 17:24 UTC, Jacek Piskozub
no flags Details

Description Jacek Piskozub 2008-05-30 10:24:35 UTC
Description of problem: rsync is unable to copy files into a mounted vfat
partition: neither from a remote server nor locally while other tools (including
wget and cp) are able. This problem appeared the moment I made the Fedora 8 -> 9
upgrade.

Version-Release number of selected component (if applicable):

Fedora 9 fully upgraded (x86)
kernel-2.6.25.3-18.fc9.i686
rsync-3.0.2-0.fc9.i386

How reproducible:

Always. I synchronize the host daily with a file server therefore I noticed it
an hour after the Fedora 8 -> 9 upgrade. 

Steps to Reproduce:
1. mount a vfat partition
2. make cd to the partition (either as a user or root - this changes nothing)
3. make "rsync directory/file ." or "rsync host:directory/file .". I usually use
 rsync with -avzu but skipping the options changes nothing
4. See rsync fail
  
Actual results:

Result of the following command: "rsync -avzu /home/piskozub/Klaster* .":

====results begin===
sending incremental file list
Klaster-raport01.odt
rsync: mkstemp "/disk_c/.Klaster-raport01.odt.ApsHuV" failed: Operation not
permitted (1)

sent 14911 bytes  received 31 bytes  29884.00 bytes/sec
total size is 16126  speedup is 1.08
rsync error: some files could not be transferred (code 23) at main.c(1031)
[sender=3.0.2]

===results end===


Expected results:

file copied.

Additional info:

This is how I mount he partition using an /etc/fstab entry:

LABEL=ASUS   /disk_c vfat  defaults,umask=027,uid=500,gid=500 0 0

This has always worked on previous Fedora versions. It still works with all file
transferring techniques I tested: remotely wget, locally cp or mv).

usid and gid are correct (I am user 500 from group 500). Changing the umask or
even running rsync  as root does not help.

Comment 1 Jacek Piskozub 2008-05-30 15:51:37 UTC
Some more info: 

This is kernel dependant, therefore it may be a kernel bug:

On Fedora 9, I still had the latest F8 kernel installed. I tested both:

kernel-2.6.24.7-92.fc8.i686 -> Works For Me (as it did under Fedora 8)
kernel-2.6.25.3-18.fc9.i686 -> this very bug


My /etc/sysconfig/i18n says:

LANG="en_US.UTF-8"
SYSFONT="latarcyrheb-sun16"

in case it is relevant.


Comment 2 Jacek Piskozub 2008-05-30 15:53:18 UTC
changing summary adding the "bad" kernel number

Comment 3 Jacek Piskozub 2008-05-30 16:20:02 UTC
I also tested it on the "updates testing" kernel-2.6.25.4-30.fc9.i686. No luck.

Comment 4 Chuck Ebbert 2008-05-30 16:26:15 UTC
Can you strace the failing rsync program and post the results as an attachment?


Comment 5 Simo Sorce 2008-05-30 16:33:10 UTC
assigning to kernel component

Comment 6 Jacek Piskozub 2008-05-30 16:59:03 UTC
Created attachment 307215 [details]
Strace of the failed rsync

I'm not sure if this will help. It seems it happened outside rsync.

Comment 7 Jacek Piskozub 2008-05-30 17:24:28 UTC
Created attachment 307217 [details]
Strace of the successful rsync under kernel 2.6.24

In case it helps.

Comment 8 Jacek Piskozub 2008-06-11 20:10:09 UTC
Now, after the release of kernel kernel-2.6.25.4-10.fc8, this became also a
Fedora 8 problem.

Comment 9 Chuck Ebbert 2008-06-11 22:00:34 UTC
Same as bug 450493 in F9

Comment 10 Chuck Ebbert 2008-06-11 22:01:43 UTC
oops bug 450493 in an F8 bug

Comment 11 Jacek Piskozub 2008-06-14 21:38:12 UTC
I did more tests today with the new F9 kernel (kernel-2.6.25.6-55.fc9).

There was one thing I most probably missed originally. Skipping -p (or -a which
is equivalent with -p among other things) make it possible to rsync into the
vfat partition. 

In the case of -a, it should be replaced with -rt (the other components of -a
most probably do not work on vfat anyway).

I included the info into the bug summary. Because there is a workaround, I also
decreased the severity to "medium".

Comment 12 Chuck Ebbert 2008-06-15 21:14:56 UTC
Fix went in kernel-2.6.25.6-63

Comment 13 Fedora Update System 2008-06-30 16:33:52 UTC
kernel-2.6.25.9-76.fc9 has been submitted as an update for Fedora 9

Comment 14 Fedora Update System 2008-07-01 05:28:23 UTC
kernel-2.6.25.9-76.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5893

Comment 15 Naveed Hasan 2008-07-01 08:30:04 UTC
I had to use 'rsync -rltoDcv' instead of 'rsync -acv' when writing to mounted
vfat media and will test this new kernel to see if the regression has been
fixed. Either the '-p' or '-g' options impled by '-a' were causing the mkstemp
failed error described above.

Comment 16 Fedora Update System 2008-07-02 06:34:36 UTC
kernel-2.6.25.9-76.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2008-07-04 03:40:13 UTC
kernel-2.6.25.9-76.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.