preallocated file size

[Cole, Timothy D.]

> -----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?