Is there anyone actively working on adding recursive operations to sftp? I've got a recent snapshot of the source (Dec 6th), and I see extended options for ls and the inclusion of history, both of which are welcome, but there doesn't seem to be any hint of recursive operation support. If there are people working quietly on recursive op patches, I'd like to hear from you. I've been putting some things together for a patch, and it would be best if we can avoid duplication of effort. I'd also like to hear from the maintainers regarding what they would deem acceptable as a patch that adds recursive operations. In past discussions, fts has been recommended. I've written put -r code using fts. It's straightforward, as suggested by Ben Lidstrom in the comments for bug 520, but as far as I know, no work has been done on making fts capable of dealing with remote operations. Are recursive operations based on a modified form of fts the only sort of patch acceptable? I've got a patch for recursive rm, too, but it uses recursion to accomplish its task. (There may be some concern about the safety of rm -r, as well.) The logic in the rm -r patch could easily be applied to other cases, like chown/chmod -R, if those are interesting to people. If modified fts is required, I'm interested in at least hearing what those modifications would need to be. Regards, andrew
Andrew Mortensen wrote:> If modified fts is required, I'm interested in at least hearing what > those modifications would need to be.Maybe you're not suggesting this, but it's my understanding the best path to 'get -r' isn't to change the fts family of functions to receive a local call and then traverse a remote directory tree, but instead to port the fts family of calls into openbsd-compat and mirror the 'put -r' code for 'get -r' commands on the server-side. (That is, pass the fts system calls and arguments down the pipe from sftp to the sftp-server a la remote_glob.) This also has the benefit of giving fts functionality to more platforms. fts didn't work natively on some other OSs (eg RH9) last year. Has the availability of the functions changed in that time to be more widely supported? Though I've since lost the revision history (grrr), I have a similar 'put -r' patch that I stopped working on some time ago. I agree, it was straightforward to implement and the 'get' command is where things become tricky. I will try to dig my patch out of the snapshot I was working against at the time and attach it to bug 520. You may find it useful to compare against though I have my doubts that it will apply cleanly against a modern snapshot without some leg work. Chase
Andrew Mortensen wrote:> Is there anyone actively working on adding recursive operations to > sftp?I'm not actively working on it, but I would really like to have it :)> If there are people working quietly on recursive op patches, I'd like > to hear from you. I've been putting some things together for a patch, > and it would be best if we can avoid duplication of effort. I'd also > like to hear from the maintainers regarding what they would deem > acceptable as a patch that adds recursive operations. In past > discussions, fts has been recommended. I've written put -r code using > fts. It's straightforward, as suggested by Ben Lidstrom in the comments > for bug 520, but as far as I know, no work has been done on making fts > capable of dealing with remote operations.Please send this to the list, or attach it to bugzilla. I don't think that we need to wait to have both get -r and put -r implemented before adding support for one of them.> Are recursive operations based on a modified form of fts the only sort > of patch acceptable? I've got a patch for recursive rm, too, but it > uses recursion to accomplish its task.Yeah, I'm quite wary of recursion to accomplish this - an attacker could mount a DoS against you by building a deep hierarchy. rm is also problematic because of race conditions in the protocol - it lacks a "moral equivalent" of O_NOFOLLOW. A modified fts() seems to be a fairly easy way to do this iteratively, but I'm certainly happy to hear other approaches. -d