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

David-Sarah Hopwood david-sarah at jacaranda.org
Sun Feb 7 01:50:26 UTC 2010

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?

>>> 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?

> 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?

After testing that, please apply the patch that I just attached to bug #645:
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
 - run "python setup.py install"
 - restart the node
 - repeat the same tests using the same clients

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
 - 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20100207/11583cc5/attachment.asc>

More information about the tahoe-dev mailing list