openssh unix dev - Jun 2019 - sftp client: upload from pipe

Damien Miller wrote:
> IIRC it's there because reads on named pipes can hang if nothing is
> attached to them
And what is the problem with that? It should break nothing if this named
pipe was passed to sftp explicitly (I'm not talking about recursively
uploading of directory that contains named pipes). Besides, there is
O_NONBLOCK if it would be very necessary.
> and because reading from devices can have side-effects (classic example
> being /dev/mt)
As above, what is the problem with that? Nobody tells anybody to use
sftp with such devices. Sometimes, It could even be desirable if e.g.
somebody would like to backup content of device on remote host via sftp.
Again as above, I'm not talking about recursively uploading of directory
that contains devices; only devices that are explicitly specified in
command. If it would be a big problem, it's ok for me that sftp could
allow uploading regular files and pipes/fifos only.

On Sat, 22 Jun 2019, Adam Osuchowski wrote:
> Damien Miller wrote:
> > IIRC it's there because reads on named pipes can hang if nothing
is
> > attached to them
> 
> And what is the problem with that?
That it can hang peoples transfers unexpectedly.
> It should break nothing if this named
> pipe was passed to sftp explicitly (I'm not talking about recursively
> uploading of directory that contains named pipes). Besides, there is
> O_NONBLOCK if it would be very necessary.
O_NONBLOCK is not a solution. There's no way to discern between "this
FIFO
has nothing connected" and "this FIFO just needs a moment to
start".
> > and because reading from devices can have side-effects (classic
example
> > being /dev/mt)
> 
> As above, what is the problem with that?
Same as above.
>  Nobody tells anybody to use
> sftp with such devices. Sometimes, It could even be desirable if e.g.
> somebody would like to backup content of device on remote host via sftp.
> Again as above, I'm not talking about recursively uploading of
directory
It's not just recursion that causes surprises, but wildcards. Say
"put /tmp/foo*" and one of the entries is a FIFO or device.
> that contains devices; only devices that are explicitly specified in
> command. If it would be a big problem, it's ok for me that sftp could
> allow uploading regular files and pipes/fifos only.
IMO the best user experience is to refuse to handle them. I'm happy to
leave sftp with some corner-case limitiations in return for it being a
generally more reliable tool.

-d

Damien Miller wrote:
> IMO the best user experience is to refuse to handle them. I'm happy to
> leave sftp with some corner-case limitiations in return for it being a
> generally more reliable tool.
And can you agree to and make an exception for pipe attached to stdin?
Because, in fact, it's a case I'm concerned with. It could be handled
with special put command syntax, e.g. with dash:

sftp> put - /directory/file

so that there was no need to cope with all pipes/fifos cases.