Comment 1 Henrik Andersson 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 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 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 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 2019-02-07 15:45:05 CET

rdesktop (and associated tools) is being removed from the ThinLinc product.