ftruncate returning EPERM on vfat filesystem

ftruncate returning EPERM on vfat filesystem

[Dave]

Hi everyone,

I experienced a strange problem after upgrading from 2.4.0-test12 to the
2.4.0 kernel.  My samba configuration stopped working.  Reverting back to
2.4.0-test12, it magically starts working again.

(2.4.0 also hard-locked my machine before I noticed this problem, but
I'll report that later when I work out why.)

I share a local vfat filesystem to a windows machine.  With 2.4.0, the
client kept randomly reporting "...Access is denied.. Make sure the disk
is not full or write-protected..." when transferring files to this
machine.  After much cursing and hair-pulling, I straced samba under both
kernels, and found out that ftruncate was returning EPERM under 2.4.0.

After diffing between 2.4.0-test12 and 2.4.0, i found this little chunk
in fat_notify_change() which may explain the problem:

diff -u --new-file --recursive linux-2.4.0-test12/fs/fat/inode.c linux-2.4.0/fs/fat/inode.c
--- linux-2.4.0-test12/fs/fat/inode.c   Tue Dec  5 13:00:44 2000
+++ linux-2.4.0/fs/fat/inode.c  Mon Jan  1 05:02:21 2001
@@ -903,6 +903,12 @@
        struct super_block *sb = dentry->d_sb;
        struct inode *inode = dentry->d_inode;
        int error;
+
+       /* FAT cannot truncate to a longer file */
+       if (attr->ia_valid & ATTR_SIZE) {
+               if (attr->ia_size > inode->i_size)
+                       return -EPERM;
+       }

        error = inode_change_ok(inode, attr);
        if (error)

Can someone tell me if this is the cause of my samba problems, and if
so, why this was added and if this is safe to revert?

TIA.

David.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ftruncate returning EPERM on vfat filesystem

[Alan Cox]

> +
> +       /* FAT cannot truncate to a longer file */
> +       if (attr->ia_valid & ATTR_SIZE) {
> +               if (attr->ia_size > inode->i_size)
> +                       return -EPERM;
> +       }
> 
>         error = inode_change_ok(inode, attr);
>         if (error)
> 
> Can someone tell me if this is the cause of my samba problems, and if
> so, why this was added and if this is safe to revert?

To stop a case where the fs gets corrupted otherwise. You can change that to
return 0 which is more correct but most not remove it.

(ftruncate is specified to make the file at most length bytes long, extending
the file is not a guaranteed side effect according to the docs I have)



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ftruncate returning EPERM on vfat filesystem

[Dave]

Hi Alan,

On Sun, 7 Jan 2001, Alan Cox wrote:

> I wrote:
> > +
> > +       /* FAT cannot truncate to a longer file */
> > +       if (attr->ia_valid & ATTR_SIZE) {
> > +               if (attr->ia_size > inode->i_size)
> > +                       return -EPERM;
> > +       }
> >
> >         error = inode_change_ok(inode, attr);
> >         if (error)
> >
> > Can someone tell me if this is the cause of my samba problems, and if
> > so, why this was added and if this is safe to revert?
>
> To stop a case where the fs gets corrupted otherwise. You can change that to
> return 0 which is more correct but most not remove it.

Ok.  Glad I didn't try it. ;)

> (ftruncate is specified to make the file at most length bytes long, extending
> the file is not a guaranteed side effect according to the docs I have)

I don't understand why samba is doing it, if infact it is.
(haven't checked the source yet, and too tired to care atm)

Two other people told me to try your 2.4.0 tree, as it has some FAT
growing-truncate patches (I can't test it until later today).  I'm
guessing (hoping) that -ac3 will fix this problem.


Thanks alot for your help.

David.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ftruncate returning EPERM on vfat filesystem

[Daniel Phillips]

Alan Cox wrote:
> 
> > +
> > +       /* FAT cannot truncate to a longer file */
> > +       if (attr->ia_valid & ATTR_SIZE) {
> > +               if (attr->ia_size > inode->i_size)
> > +                       return -EPERM;
> > +       }
> >
> >         error = inode_change_ok(inode, attr);
> >         if (error)
> >
> > Can someone tell me if this is the cause of my samba problems, and if
> > so, why this was added and if this is safe to revert?
> 
> To stop a case where the fs gets corrupted otherwise. You can change that to
> return 0 which is more correct but most not remove it.
> 
> (ftruncate is specified to make the file at most length bytes long, extending
> the file is not a guaranteed side effect according to the docs I have)

Speaking as an old time dos hacker, this is allowed and commonly done. 
I wouldn't read too much into the fact that it's not documented.  :-) 
As I recall, new clusters are allocated but not cleared.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: ftruncate returning EPERM on vfat filesystem

[Richard Henderson]

On Sun, Jan 07, 2001 at 01:55:15PM +0000, Alan Cox wrote:
> > +                       return -EPERM;
> 
> To stop a case where the fs gets corrupted otherwise. You can change that to
> return 0 which is more correct but most not remove it.

While I suppose "0" is covered under "the result is unspecified", I
would suggest that EINVAL is a better choice: "The filedes argument
does not refer to a file on which this operation is possible".

The reason being that the normal reason for an extending ftruncate
is so that you can mmap it and not get SIGBUS for accessing past the
end of the file.


r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/