Bugzilla – Full Text Bug Listing
|Summary:||Copying of large files to local USB drive with FAT fails with rdesktop|
|Product:||ThinLinc||Reporter:||Thomas Nilefalk <firstname.lastname@example.org>|
|Component:||| rdesktop (deprecated)||Assignee:||Karl Mikaelsson <email@example.com>|
|Status:||CLOSED WONTFIX||QA Contact:||Bugzilla mail exporter <firstname.lastname@example.org>|
|Bug Depends on:|
This scenario fails: Given a file on the server larger than 512MB And a local USB drive with FAT file system When drag-and-drop the file from the server to the USB Then a progress indicator should be visible and incrementing And the file should be copied Currently rdesktop becomes unresponsive when the copying starts and does not show any progress. The copying seems to timeout and end with a "No space on device". Under some circumstances (race condition?) you first get a prompt "File already exists", which can be circumvented with "Replace". Detailed investigation seems to indicate that `ftruncate_growable()` needs to handle this manually and it takes a lot of time in the given scenario.
I have tested rdesktop with a local drive redirection of a USB memory formatted with VFAT. When copying a file from within the session to the USB memory, it takes a few seconds, depending on how big file you copy, before the actual copy of data starts. During this time the usb memory writes some data and rdesktop becomes unresponsive, a few graphical updates happens during the time happens. This problem is linear with the size of file that is copied, smaller file, smaller hang, bigger file, longer hang. I identified that there is a sync() happening in the hang and that before a copy to the file starts it creates a file allocation of the file first. I found that ftruncate_growable() in rdesktop is the reason for this. The function is responsible for preallocating a file using ftruncate() using a length beyond actual file size. There are cases of filesystems where a call to ftruncate() with a length bigger then actual file fails, and ftruncate_growable() handles this and uses a fallback code which is results a sync(). I verified that if I have ext3 filesystem on my usb memory there is no hang at all, and the first call ftruncate() with length beyond eof works as expected, and does not produce a sync().
There is an additional problem where an NFS operation times out and raises en EIO error. Local drive redirection mount options defines a timeout of 5 seconds with one extra retry, this equals to: No NFS operation can never exceed 10 seconds and such operation will fail with EIO. To produce such error, mount an USB device and run following command which sends a NFS SETATTR to resize the file, with a reply 2 minutes later well beyond the 10 seconds timeout explained above: truncate -s $((2024*1024*1024)) data.raw
(In reply to comment #2) > There is an additional problem where an NFS operation times out and raises en > EIO error. Local drive redirection mount options defines a timeout of 5 seconds > with one extra retry, this equals to: No NFS operation can never exceed 10 > seconds and such operation will fail with EIO. > > To produce such error, mount an USB device and run following command which > sends a NFS SETATTR to resize the file, with a reply 2 minutes later well > beyond the 10 seconds timeout explained above: > > truncate -s $((2024*1024*1024)) data.raw This could definitely be the reason for the problem described on bug 5671  https://www.cendio.com/bugzilla/show_bug.cgi?id=5671
We need to have a deeper investigation and discussion about what problems we have here and how the current timeouts interact with that.