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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
