On Wed, 6 Dec 2000, Alexander Viro wrote:
> They are not Linux-specific (check where they came from), so I would rather
> check 4.4BSD and SuSv2[1] be damned. I'll look it up tomorrow, right now I'm
> going down. Sorry.
4.4BSD (FreeBSD 4.2-release) returns EPERM for truncate on immutable (schg
or
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> > error = -EPERM;
> > if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
> > goto dput_and_out;
>
> also, while we are here -- are you sure that EPERM is a good idea for
> IS_IMMUTABLE(inode
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> error = -EPERM;
> if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
> goto dput_and_out;
also, while we are here -- are you sure that EPERM is a good idea for
IS_IMMUTABLE(inode)? Other parts of Linux return EACCES in this
case. Ma
On Wed, 6 Dec 2000, Tigran Aivazian wrote:
> minutes ago... maybe you could merge it into yours and re-send to Linus?
here is the merged patch:
--- linux/fs/open.c Thu Oct 26 16:11:21 2000
+++ work/fs/open.c Wed Dec 6 07:38:30 2000
@@ -102,7 +102,12 @@
goto out;
Oh, Alexander your patch conflicts (well, not strictly but causes
patch(1) to spew warnings) with the one I just wanted to send to Linus 10
minutes ago... maybe you could merge it into yours and re-send to Linus?
Mine is obvious, see below (vfs_permission does have enough to fail with
EROFS on a
ext2_get_block() should return -EFBIG if the block number is
too large for our block size. It returns -EIO and prints a warning
right now. Fix: don't generate bogus warnings (we can legitimately
get larger-than-maximum arguments; there is no way in hell VFS or VM
could know the ext2-specif
truncate() and ftruncate() return values are different from the
POSIX requirements and from the values returned by other Unices (and from
our own manpages, BTW). Trivial fix follows. Rationale: see truncate(2),
ftruncate(2), POSIX or try to call the thing on other Unices.
Please,
If get_block() fails in block_prepare_write() we should zero
the blocks we've allocated and mark them dirty. We don't (i.e. we leave
the random junk in file in that case). Fix: do it. Moreover, if
->prepare_write() fails generic_file_write() is not going to write the user's
data into that
ext2_update_inode() marks the filesystems as having large files
if there the file becomes too large for old driver (2.2 one). Unfortunately,
it gets the limit wrong - it's not 2^32, it's 2^31. So we should check
for ->i_size_high being non zero _or_ ->i_size having bit 31 set. Please,
appl
9 matches
Mail list logo
