preallocated file size

[Nicolas Williams]

On Tue, Feb 08, 2000 at 01:02:57PM -0500, Cole, Timothy D. wrote:
> > -----Original Message-----
> > From:	Nicolas Williams [SMTP:Nicolas.Williams at wdr.com]
> > Sent:	Monday, February 07, 2000 12:15
> > To:	Multiple recipients of list SAMBA-TECHNICAL
> > Subject:	Re: preallocated file size
> > 
> > On Mon, 7 Feb 100, jeremy at varesearch.com wrote:
> > > > My initial thoughts go like this: 
> > > > 
> > > > typedef struct file_fd_struct { 
> > > > ... 
> > > > BOOL check_for_write_at_end; 
> > > > } file_fd_struct; 
> > > > 
> > > > in smbd/open.c open_file() 
> > > > fds->check_for_write_at_end = True; 
> > > > ... 
> > > > 
> > > > in <the initial write> 
> > > > if ( fds->check_for_write_at_end == True 
> > > > && requested_position != 0) { 
> > > > /* Then application was writing the last block */ 
> > > > /* of the file first to see if we have enough space. 
> > > > */ 
> > > > 
> > > > fds->check_for_write_at_end == False; 
> > > > 
> > > > length = requested_position + len; 
> > > > (void) fstatvfs(fds->fd, buf); 
> > > > if (length >= (buf.f_bavail*buf.f_frsize)) { 
> > > > /* Then the copy will fail eventually, so */ 
> > > > /* report it now. This will avoid NT (Win2K) 
> > > > */ 
> > > > /* assuming it can't fail, and then */ 
> > > > /* running out of space. The latter leaves */ 
> > > > /* files full of nulls as the result of a */ 
> > 
> > Well, I think that the 'check_for_write_at_end' flag should be checked
> > only if the write fails, then do something (such as truncation the file
> > to 0, to the place where the write failed or unlink the file).
> > 
> > Alternatively see my previous post, where I suggest that Samba prevent
> > the creation of holey files by SMB clients in the first place.
> > 
> > > I may be away, but through the magic of the internet 
> > > (and the Computing in High Energy Physics conference :-) I'm still
> > trying 
> > > to get work done :-) :-). 
> > > 
> > > We could prbably do a simpler (and nastier :-) fix, by assuming 
> > > that if a write fails with ENOSPC, then we should truncate at 
> > > the requested seek postion for the file. Hmmm. I can see problems 
> > > with this though - and I *hate* the idea of adding the overhead 
> > > above to fix what is essentially a client bug... 
> > 
> > Even simpler might be the no-holey-files-by-smb-clients fix.
> > 
> 	What if the SMB client is a Unix system?
> 

What about that? I mean, CIFS doesn't seem to allow for holey-files,
right? Though I imagine the specs say nothing of the subject, so it's
really a matter of practice vs. spec then.

So let the Unix clients use a different protocol. It's not like there
aren't any (Sun is paying for an implementation of NFSv4 for Linux;
NFSv4 appears to be stateful, not just in that it allows for NFS over
TCP, but in that it now has OPEN/CLOSE RPC calls!).

Besides, what's the common case? Windows or Unix SMB clients?

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.