Bug 7046 - Copying of large files to local USB drive with FAT fails with rdesktop
Summary: Copying of large files to local USB drive with FAT fails with rdesktop
Status: CLOSED WONTFIX
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: | rdesktop (deprecated) (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.10.0
Assignee: Karl Mikaelsson
URL:
Keywords:
Depends on:
Blocks: 6096
  Show dependency treegraph
 
Reported: 2017-09-13 10:01 CEST by Thomas Nilefalk
Modified: 2019-02-07 15:52 CET (History)
2 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Thomas Nilefalk cendio 2017-09-13 10:01:46 CEST
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.
Comment 1 Henrik Andersson cendio 2017-09-26 10:12:41 CEST
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().
Comment 2 Henrik Andersson cendio 2017-10-02 13:00:22 CEST
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
Comment 3 Henrik Andersson cendio 2017-10-02 13:05:15 CEST
(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 [1]

https://www.cendio.com/bugzilla/show_bug.cgi?id=5671
Comment 4 Pierre Ossman cendio 2017-10-03 14:03:10 CEST
We need to have a deeper investigation and discussion about what problems we have here and how the current timeouts interact with that.
Comment 6 Pierre Ossman cendio 2019-02-07 15:45:05 CET
rdesktop (and associated tools) is being removed from the ThinLinc product.

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