Adds support for SharedDirectoryTruncateRequest and SharedDirectoryTruncateResponse messages
#40068
Conversation
…uncateResponse messages
github-actions
bot
added
desktop-access
rdp
rfd
| default: | ||
| this.logger.warn(`received unsupported message type ${messageType}`); |
There was a problem hiding this comment.
Looks like this is backwards compatible by default because an old client will hit this default case and log the message but otherwise continue to function. Is that right?
There was a problem hiding this comment.
Yeah, the truncate would simply be ignored were it to reach here. However, that would mean we have a vN w_d_s operating with a v(N-1) proxy, which iirc isn't supported in general.
Presuming that, we don't have to worry about backwards compatibility when adding new server-initiated message chains (such as this one).
| | message type (33) | completion_id uint32 | directory_id uint32 | path_length uint32 | path []byte | end_of_file uint32 | | ||
| ``` | ||
|
|
||
| This message is sent by the server to the client to request a file be truncated to `end_of_file` bytes. |
There was a problem hiding this comment.
Can we be more specific w.r.t what is the server and what is the client.
In standard RDP it's pretty clear, but our architecture introduces some ambiguity - the w_d_s is an RDP client, but can also be considered the server to our web-based client.
There was a problem hiding this comment.
I added a note on the terminology in 197a123
| @@ -622,6 +622,15 @@ func (c *Client) startInputStreaming(stopCh chan struct{}) error { | |||
| return trace.Errorf("SharedDirectoryMoveResponse failed: %v", errCode) | |||
| } | |||
| } | |||
| case tdp.SharedDirectoryTruncateResponse: | |||
There was a problem hiding this comment.
Do we need some backwards compat logic here, or is the thought that we will never send a response to an old w_d_s that doesn't understand it because said w_d_s would have never sent the initial request?
There was a problem hiding this comment.
we will never send a response to an old w_d_s that doesn't understand it because said w_d_s would have never sent the initial request?
Yes, only a w_d_s that sends a truncate request will ever receive a truncate response, and all w_d_s's that send truncate requests can handle truncate responses.
|
@ibeckermayer See the table below for backport results.
|
Fixes #35269
changelog: Fixes a bug in desktop directory sharing which was preventing files from being properly truncated.
Due to the rust overhaul in v15, it would be a separate project to "backport" this to v13 and v14; for that reason I am going to let the bug stand in those versions barring specific complaints by customers.