[9fans] losing files with ftpfs(4)

[9fans] losing files with ftpfs(4)

[Alberto Cortes]

I have an ftp server (no plan9 host), it serve some files and
directories.

When a client connects to my ftp server it shows a write protected
directory containing some readable files and some writable
directories.

If i ftpfs to it and try to "mv" a file to the mount point (write
protected) this happens:

term% ftpfs -m /usr/glenda/ftp -a xxxx@yyyyy.com 172.26.0.4
220 ProFTPD 1.2.5rc1 Server (Debian) [shire]
331 Anonymous login ok, send your complete email address as your password.
230 Anonymous access granted, restrictions apply.
215 UNIX Type: L8
257 "/" is current directory.
term% mv foo ftp/
226-Transfer complete.
ftpfs: couldn't create file 

Which is quite annoying as i find myself with no "foo" file on the ftp
server (that's OK) AND no "foo" file on my plan9 side (which is
certainly not OK).

Is this the expected behaviour of ftpfs ?

Could it be that "ftpfs" isn't checking for permission before saying
"mv": "i can handle this, just finish your work" ?


sorry for not tracking the problem much more but i am not very
experienced with this things.


-- 
http://montoya.aig.uc3m.es/~acortes/index.html

Re: [9fans] losing files with ftpfs(4)

[Russ Cox]

This is just a fundamental limitation of ftpfs.
It can't reliably try the create until it has all
the data that is supposed to be in the file.
But it doesn't know it has all the data until
the close, at which point mv will think it's
okay to remove the original.

Russ

Re: [9fans] losing files with ftpfs(4)

[boyd, rounin]

> This is just a fundamental limitation of ftpfs.
> It can't reliably try the create until it has all
> the data that is supposed to be in the file.
> But it doesn't know it has all the data until
> the close, at which point mv will think it's
> okay to remove the original.

1 point for NFS's rename call. -2 points for NFS's lack
of a close op and writes in a 'random' order.

ftp's RNFR/RNTO ops do mv(1).

not that i'm advocating breaking mv.

did this 'disk full' patch get applied?

brahma% diff /n/sources/plan9/sys/src/cmd/ip/ftpfs/proto.c .
991,992c991
< getreply(&ctlin, msg, sizeof(msg), 0);
< return off;
---
> return getreply(&ctlin, msg, sizeof(msg), 0) == Success ? off : -1;

Re: [9fans] losing files with ftpfs(4)

[jmk]

On Tue Sep  7 18:08:07 EDT 2004, boyd@insultant.net wrote:
> ...
> did this 'disk full' patch get applied?
> 
> brahma% diff /n/sources/plan9/sys/src/cmd/ip/ftpfs/proto.c .
> 991,992c991
> < getreply(&ctlin, msg, sizeof(msg), 0);
> < return off;
> ---
> > return getreply(&ctlin, msg, sizeof(msg), 0) == Success ? off : -1;

yes

Re: [9fans] losing files with ftpfs(4)

[boyd, rounin]

> yes

thanks

Re: [9fans] losing files with ftpfs(4)

[Joseph Holsten]

Why can't it create an empty file to test write access, and then
rewrite the file after it receives it?

Re: [9fans] losing files with ftpfs(4)

[Russ Cox]

> Why can't it create an empty file to test write access, and then
> rewrite the file after it receives it?

Ftpfs could employ all sorts of heuristics, but it still
won't get the semantics right 100%.  I agree that your 
heuristic is probably worth implementing, but there
aren't many people who want to go near that code.

We typically use ftpfs as read-only.  For writing, you're
better off with u9fs, perhaps invoked over ssh.

Russ