[patch] s_maxbytes handling

[patch] s_maxbytes handling

[Andrew Morton]

If ->f_pos is positioned exactly at sb->s_maxbytes, a non-zero-length
write to the file doesn't write anything, and write() returns zero.

Consequently applications which try to append to a file which
is s_maxbytes in length hang up, because write() just keeps
on returning zero.

We need to return -EFBIG if ->f_pos is at s_maxbytes and
the length is non-zero.

--- linux-2.4.5-pre4/mm/filemap.c	Mon May 21 20:03:03 2001
+++ linux-akpm/mm/filemap.c	Tue May 22 22:34:41 2001
@@ -2571,11 +2571,13 @@
 	 *	Linus frestrict idea will clean these up nicely..
 	 */
 	 
-	if (pos > inode->i_sb->s_maxbytes)
-	{
-		send_sig(SIGXFSZ, current, 0);
-		err = -EFBIG;
-		goto out;	
+	if (pos >= inode->i_sb->s_maxbytes) {
+		if (count || pos > inode->i_sb->s_maxbytes) {
+			send_sig(SIGXFSZ, current, 0);
+			err = -EFBIG;
+			goto out;
+		}
+		/* zero-length writes at ->s_maxbytes are OK */
 	}
 
 	if (pos + count > inode->i_sb->s_maxbytes)

Re: [patch] s_maxbytes handling

[Alan Cox]

> If ->f_pos is positioned exactly at sb->s_maxbytes, a non-zero-length
> write to the file doesn't write anything, and write() returns zero.

Are you absolutely sure here. Because I ran that code through a set of standards
verification tests. So unless you can cite page and paragraph from SuS and
the LFS spec I think the 0 might in fact be correct..

Alan

Re: [patch] s_maxbytes handling

[Andrew Morton]

Alan Cox wrote:
> 
> > If ->f_pos is positioned exactly at sb->s_maxbytes, a non-zero-length
> > write to the file doesn't write anything, and write() returns zero.
> 
> Are you absolutely sure here. Because I ran that code through a set of standards
> verification tests. So unless you can cite page and paragraph from SuS and
> the LFS spec I think the 0 might in fact be correct..

I don't know the standards Alan, but returning zero
from write() when f_pos is at s_maxbytes will make
a lot of apps hang up.  dd, bash and zsh certainly do.

Are they buggy?  Should they be testing the return value
of write() and assuming that zero is file-full?

The s_maxbytes logic is different from the
MAX_NON_LFS logic:

        /*
         *      LFS rule 
         */
        if ( pos + count > MAX_NON_LFS && !(file->f_flags&O_LARGEFILE)) {
                if (pos >= MAX_NON_LFS) {
                        send_sig(SIGXFSZ, current, 0);
                        goto out;
                }

This makes more sense.  If the file is full, and
you're trying to grow it, you fail.

Re: [patch] s_maxbytes handling

[Alan Cox]

> > verification tests. So unless you can cite page and paragraph from SuS and
> > the LFS spec I think the 0 might in fact be correct..
> 
> I don't know the standards Alan, but returning zero
> from write() when f_pos is at s_maxbytes will make
> a lot of apps hang up.  dd, bash and zsh certainly do.

> Are they buggy?  Should they be testing the return value
> of write() and assuming that zero is file-full?

0 is an EOF.

> The s_maxbytes logic is different from the
> MAX_NON_LFS logic:
> 
>         /*
>          *      LFS rule 
>          */
>         if ( pos + count > MAX_NON_LFS && !(file->f_flags&O_LARGEFILE)) {
>                 if (pos >= MAX_NON_LFS) {
>                         send_sig(SIGXFSZ, current, 0);
>                         goto out;
>                 }
> 
> This makes more sense.  If the file is full, and
> you're trying to grow it, you fail.

The spec says of write

DESCRIPTION

     For regular files, no data transfer will occur past the offset
     maximum established in the open file description associated with
     fildes.

     [EFBIG]
          The file is a regular file, nbyte is greater than 0 and the
          starting position is greater than or equal to the offset
          maximum established in the open file description associated
          with fildes.

Which seems to say to me that if we write > 0 bytes and we start at or
on the boundary we should error - which would agree with your change.

Alan

Re: [patch] s_maxbytes handling

[Linus Torvalds]

In article <E152Dik-00021y-00@the-village.bc.nu>,
Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
>> > verification tests. So unless you can cite page and paragraph from SuS and
>> > the LFS spec I think the 0 might in fact be correct..
>> 
>> I don't know the standards Alan, but returning zero
>> from write() when f_pos is at s_maxbytes will make
>> a lot of apps hang up.  dd, bash and zsh certainly do.
>
>> Are they buggy?  Should they be testing the return value
>> of write() and assuming that zero is file-full?
>
>0 is an EOF.

0 is EOF _for_reads_. For writes it is not very well defined (except for
the special case of a zero-sized write to a regular file).

For writes, 0 has historically been what Linux has returned for various
"disk full" conditions, and seems to be what programs such a "tar"
actually expected for end of disk.  Also, traditionally a lot of UNIXes
returned 0 when O_NDELAY was set and they couldn't write anything (ie
the modern EAGAIN). 

An application seeing a zero return from a write with a non-zero buffer
size cannot really assume much about what it means. The best you can
probably do is to fall back and say "no more space on device", but
obviously a lot of programmers who are used to testing only for _real_
errors will not even think about considering 0 an error value.

So returning 0 for write() is usually a bad idea - exactly because it
does not have very well-defined semantics.  So -EFBIG is certainly the
preferable return value, and seems to be what SuS wants, too. 

		Linus

Re: [patch] s_maxbytes handling

[David N. Lombard]

Linus Torvalds wrote:
> 
[deletia]
> 
> So returning 0 for write() is usually a bad idea - exactly because it
> does not have very well-defined semantics.  So -EFBIG is certainly the
> preferable return value, and seems to be what SuS wants, too.

And what LFS wants too:

2.2.1.27 write() and writev()

DESCRIPTION

     For regular files, no data transfer will occur past the offset
     maximum established in the open file description associated with
     fildes.

ERRORS

     These functions will fail if:

     [EFBIG]
          The file is a regular file, nbyte is greater than 0 and the
          starting position is greater than or equal to the offset
          maximum established in the open file description associated
          with fildes.

     Note: This is an additional EFBIG error condition.

-- 
David N. Lombard

Re: [patch] s_maxbytes handling

[Stephen C. Tweedie]

Hi,

On Tue, May 22, 2001 at 04:05:14PM +0100, Alan Cox wrote:

> > The s_maxbytes logic is different from the
> > MAX_NON_LFS logic:
> >         if ( pos + count > MAX_NON_LFS && !(file->f_flags&O_LARGEFILE)) {
> >                 if (pos >= MAX_NON_LFS) {
> >                         send_sig(SIGXFSZ, current, 0);
> >                         goto out;
> >                 }

> The spec says of write
>      [EFBIG]
>           The file is a regular file, nbyte is greater than 0 and the
>           starting position is greater than or equal to the offset
>           maximum established in the open file description associated
>           with fildes.
> 
> Which seems to say to me that if we write > 0 bytes and we start at or
> on the boundary we should error - which would agree with your change.

SuS also states

  If a write() requests that more bytes be written than there is room
  for (for example, the ulimit or the physical end of a medium), only as
  many bytes as there is room for will be written. For example, suppose
  there is space for 20 bytes more in a file before reaching a limit. A
  write of 512 bytes will return 20. The next write of a non-zero number
  of bytes will give a failure return (except as noted below)  and the
  implementation will generate a SIGXFSZ signal for the thread.

so SIGXFSZ plus -EFBIG returned would appear to be the correct
behaviour.  That's certainly what 2.2 used to when it encountered such
limits.

Cheers,
 Stephen

Re: [patch] s_maxbytes handling

[Andries.Brouwer]

Linus writes:

	0 is EOF _for_reads_. For writes it is not very well defined

Hmm.

	So -EFBIG is certainly the preferable return value,

Yes. The Austin 6th draft writes

EFBIG:
An attempt was made to write a file that exceeds the implementation-defined
maximum file size  or the process' file size limit, and there was no room for 
any bytes to be written.

Andries