[Twisted-Python] Collaborative file storage via ftp/sftp/smb and html

Andrew Bennetts andrew-twisted at puzzling.org
Mon Mar 1 02:56:15 EST 2004

On Mon, Mar 01, 2004 at 05:29:47PM +1000, Andy Gayton wrote:
> I'm investigating setting up a collaborative remote file share.  There 
> are a number of traditional ways for doing this, each has their 
> strengths and weaknesses:
> ftp - not secure, fast and robust file transfer, supports resume, 
> difficult to administer as unless chrooted users have access to the 
> entire file system, if chrooted its difficult to set up group, no vendor 
> lockin on the client

ftp isn't robust, either -- the multi-socket aspect of it means it often
breaks in the presence of firewalls.  It also has no agreed standard for
sharing metadata (like modification times or content types?).

> sftp - same as ftp but secure

That's almost entirely wrong :)

SFTP has very little in common with FTP.  The only similarities I can think
of are that SFTP clients are traditionally presented to look like FTP
clients, and that SFTP has per-session authentication (whereas with e.g.
HTTP you have to re-auth for every request, or at least pass auth
credientials like a session cookie for every request).  As far as I'm aware,
SFTP doesn't have the binary/ascii transfer mode gunk that FTP has, or any
of the nasty seperate data connection sockets issues.

SFTP is massively more secure than FTP, though :)

> smb - secureish, slow over wan, doesn't support resume, great to 
> administer - give exactly the access you want to who you want, easy to 
> support groups, vendor lockin on the client

I suspect that you can resume with SMB -- a network filesystem that doesn't
support accessing files in pieces (i.e. seek) is pretty limited.  Most
clients wouldn't expose this functionality, though.

> html - can be secure, slow non robust file transfer, doesn't support 
> resume, easy to administer who has access to what, client access is 
> universal

(I think you mean HTTP)

What's non-robust about HTTP, compared to FTP?  And it definitely *does*
support resuming downloads -- see the Range header:

> I'm looking at defining a virtual filesystem that can be accessed 
> eventually by all of the above the methods.
> I am going to start with conch's sftp at first and see how I go.  Just 
> thought I'd run it past the list as I get started to see if others are 
> interested and have thoughts in the area or recommendations on how this 
> should be done.

I just thought I should correct some misunderstandings about the protocols
you mentioned :)


More information about the Twisted-Python mailing list