Previously, these bits were ignored by Chmod, which sent the numerical
value of the mode argument as-is to the server. As a result, callers had
to supply POSIX values for setuid, setgid and sticky to Chmod.
The new version supports both the POSIX values and the Go values.
Also added a note to the docs to clarify that the umask is not
subtracted from the mode, and why that is. The only portable way to get
the umask is to set it, then reset it, but that's racy. On Linux, we
could parse /proc/self/status, but that doesn't work portably and will
fail where /proc is not available (some Docker containers, notably).
we need to add a case for this packet inside the packet worker otherwise
it will be handled in hasHandle case and it will become a "Put" request.
Client side if a Truncate request is called on the open file we should
send a FSETSTAT packet, the request is on the handle, and not a SETSTAT
packet that should be used for paths and not for handle.
after processing a packet we keep in memory the allocated slices and we reuse
them for new packets.
Slices are allocated in:
- recvPacket
- when we receive a sshFxpReadPacket (downloads)
The allocated slices have a fixed size = maxMsgLength.
Allocated slices are referenced to the request order id and are marked for reuse
after a request is served in maybeSendPackets.
The allocator is added to the packetManager struct and it is cleaned at the end
of the Serve() function.
This allocation mode is optional and disabled by default
Before this change in File.WriteTo() we used Fstat to discover the
length of the file being transferred. It appears that some SFTP
servers do not implement this properly perhaps because it is a seldom
used call.
After this change we replace the Fstat on the file handle with a Stat
of the path. Stat is commonly used function and implemented correctly
in both the servers that had the problem with Fstat, thus working
around the problem.
The code before and after uses the same number of SFTP roundtrips so
performance should be identical.
Fixes#288
Fixes#234
Similar to #181 (which was about read methods), the client deadlocks on
server drop on write methods (Write/ReadFrom). This is another case of
broadcastErr() and dispatchRequest() deadlocking.
The fix is to bump up the channel used to communicate about inflight
packets to maxConcurrentRequests+1 (+1 is new). It seems that it can
have the full set of packets going and hit the error (triggering
broadcastErr) yet it still tries to call dispatchRequest again. More
details in that ticket.
I'm also bumping up the chan buffer in the read methods to keep them
consistent. I can't reproduce the problem, but it looks like it should
have it. So it might just be a much harder race to trigger.
This also includes 2 tests which reprocuded the issue for ReadFrom and
Write.
Cassondra Foesch
greatroar
Cassondra Foesch
Nicola Murino
Eran Sandler
John Eikenberry
Tommie Gannert
Nick Craig-Wood
Quinton Pike
Taizeng Wu
gm42
Urjit Singh Bhatia