Jody Harris wrote: > On Sat, Feb 6, 2010 at 3:57 PM, David-Sarah Hopwood < > david-sa...@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:
<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
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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tahoe-dev mailing list tahoe-dev@allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
