From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <05e501c49526$93826a30$f5667d50@SOMA> From: "boyd, rounin" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> References: <20040907211108.GA1687@shire> Subject: Re: [9fans] losing files with ftpfs(4) Date: Wed, 8 Sep 2004 00:03:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: dfad6db6-eacd-11e9-9e20-41e7f4b1d025 > 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;