[tahoe-dev] An additional bounty for an SFTP interface

Sat Feb 6 18:30:29 PST 2010

On Sat, Feb 6, 2010 at 6:50 PM, David-Sarah Hopwood <
david-sarah at jacaranda.org> wrote:

> Jody Harris wrote:
> > On Sat, Feb 6, 2010 at 3:57 PM, David-Sarah Hopwood <
> > david-sarah at jacaranda.org> wrote:
> >> Jody Harris wrote:
> >>
> >>> For others: SFTP doc is  located in the tarball at
> >>> ~/allmydata-tahoe-1.6.0/docs/frontends/FTP-and-SFTP.txt
> >>>
> >>> Followed instructions (keys and ftp.accounts), restarted tahoe.
> >>>
> >>> port 8022 is present, but I have not yet been able to attach to the
> port.
> >>>
> >>> "Unknown error
> >>> SFTP command failed for an unknown reason."
> >>
> >> Sigh, gotta love error messages like that.
> >
> > This was from trying to connect with KDE's Dolphin filemanager using the
> > sftp kioslave....
>
> Any messages from sftpd at that point?
>
> 2010-02-06 19:09:37-0700 [SSHChannel session (0) on SSHService
ssh-connection on SSHServerTransport,11,127.0.0.1] OPENDIRECTORY /
2010-02-06 19:09:37-0700 [SSHChannel session (0) on SSHService
ssh-connection on SSHServerTransport,11,127.0.0.1] CONVERT  []
2010-02-06 19:09:37-0700 [SSHChannel session (0) on SSHService
ssh-connection on SSHServerTransport,11,127.0.0.1] ROOT <DirectoryNode
RW-MUT oen7k>
2010-02-06 19:09:37-0700 [SSHChannel session (0) on SSHService
ssh-connection on SSHServerTransport,11,127.0.0.1] PATH []
2010-02-06 19:09:37-0700 [SSHChannel session (0) on SSHService
ssh-connection on SSHServerTransport,11,127.0.0.1] Unhandled Error
        Traceback (most recent call last):
          File
"/usr/lib/python2.6/dist-packages/twisted/conch/ssh/filetransfer.py", line
53, in dataReceived
            f(data)
          File
"/usr/lib/python2.6/dist-packages/twisted/conch/ssh/filetransfer.py", line
285, in packet_READDIR
            d.addCallback(self._cbSendDirectory, requestId)
          File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py",
line 195, in addCallback
            callbackKeywords=kw)
          File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py",
line 186, in addCallbacks
            self._runCallbacks()
        --- <exception caught here> ---
          File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py",
line 328, in _runCallbacks
            self.result = callback(self.result, *args, **kw)
          File
"/usr/lib/python2.6/dist-packages/twisted/conch/ssh/filetransfer.py", line
312, in _cbSendDirectory
            data += self._packAttributes(attrs)
          File
"/usr/lib/python2.6/dist-packages/twisted/conch/ssh/filetransfer.py", line
95, in _packAttributes
            data += struct.pack('!Q', attrs['size'])
        struct.error: cannot convert argument to long

> >>> I probably missed something.
> >>
> >> sftpd.py prints debugging messages on stdout whenever it receives a
> >> request. What did it print, or did it give a traceback? Can you try
> >> clients other than the command-line sftp client?
> >>
> >> (This is done using v1.6 of tahoe.)
> >
> > I did get connected using the sftp command line client.
> >
> > {{{ls}}} fails.
> >
> > {{{mkdir testing}}} created a directory that I can see with {{{tahoe
> ls}}}.
> >
> > .... very interesting....
> >
> > I copies a files {{{tahoe cp path/to/file alias:testing/}}}, and was able
> to
> > do see it with {{{ls testing/}}} in sftp.
> >
> > I then attached to sftp://localhost:8022/testing with Dolphin, and I can
> see
> > the file.
>
> Can you see it by attaching to sftp://localhost:8022/ and then navigating
> to testing?
>
> Yes. On attaching (authorization), I get the error, but I do get connected.
After connecting, I can append testing to the path, and it opens fine.

>  > I can copy the file form the sftp-mounted directory to a local directory
> > with Dolphin.
> >
> > I cannot open the file directly from the sftp-mounted directory because
> > other programs don't have access to the kioslave.
> >
> > So the problem with with the root directory of the alias.
>
> Either with the root directory of the alias, or with empty directories.
> Can the contents of empty non-root directories be listed in each client?
>
> Empty non-root directories list without errors or warnings.

> After testing that, please apply the patch that I just attached to bug
> #645:
> <
> http://allmydata.org/trac/tahoe/raw-attachment/ticket/645/potential-fix-for-sftpd-path-handling-darcspatch.txt
> >
> and try again.
>
> To be more explicit:
>  - put the Tahoe alias directory back to the same state you started from
>     above (empty, presumably?)
>  - stop the node
>  - cd to the root of the Tahoe source tree (fetched from trunk using darcs,
>     as described in http://allmydata.org/trac/tahoe/wiki/Dev)
>  - enter "darcs apply " followed by the path to
>     potential-fix-for-sftpd-path-handling-darcspatch.txt
>  - run "python setup.py install"
>  - restart the node
>  - repeat the same tests using the same clients
>
> Okay... I got allmydata-tahoe: 1.6.0-r4228 running, but sftp for alias
roots still fails for sftp client as well as both Nautilus and Dolphin.
Subdirectories still work fine in all contexts.

> If you prefer a unified diff to a darcspatch, there's one attached to that
> bug as well. It can be applied using "patch --strip-prefix=1 <" followed by
> the path to potential-fix-for-sftpd-path-handling-udiff.txt
>
> > Apparently, not all of the information required for ftp/sftp is being
> passed
> > by tahoe through the ftp/sftp protocol.
>
> Just a tip about reporting bugs: don't speculate about the cause, unless
> you have specific evidence to support the speculation. It's easy to go down
> blind alleys that way. Here, there are quite a few possibilities for what
> *could* be wrong:
>
>  - sftpd.py could be misimplementing the SFTP protocol in some cases,
>   either doing the wrong thing and/or returning incorrect information
>   in responses
>  - sftpd.py could be correct but tickling a bug elsewhere in Tahoe (fairly
>   unlikely)
>  - one or more of the sftp clients could be misimplementing the protocol
>   (also fairly unlikely)
>  - the protocol could be ambiguously specified, and some clients rely on
> the
>   ambiguous cases while other clients avoid them.
>
> Also note that when testing a stateful system with several different
> protocol implementations, it's important to begin with the same state
> with each combination of server and client implementation (where possible).
>
> --
> David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com
>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://allmydata.org/pipermail/tahoe-dev/attachments/20100206/276bc7ff/attachment-0001.htm 