> " " == Matti Aarnio <[EMAIL PROTECTED]> writes:
> The NFSv3 CLIENT code must do post-open verification, that if
> the opened file has size exceeding 2G-1, and O_LARGEFILE flag
> is not set, the opened file must be closed, and caller must be
Just out of curiosity: why can
> " " == Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Wed, Oct 25, 2000 at 09:34:49PM +0200, Trond Myklebust
> wrote:
>> All NFSv3 operations are 64-bit and LFS-compliant. There's
>> therefore no need for an O_LARGEFILE flag.
> I don't understand what you mean, so
On Thu, Oct 26, 2000 at 03:56:46AM +0200, Andi Kleen wrote:
> a 4GB-1 file.
Side note: 4GB-2 since -1 means "ignore".
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
On Thu, Oct 26, 2000 at 12:06:17AM +0200, Andrea Arcangeli wrote:
> 2.2.18pre17aa1 allows anybody to open a file larger than 2G (that seems not to
> be completly in sync with the specs) but it has all the necessary runtime
> checks during read/write. Just search for O_LARGEFILE in the lfs patch. T
On Wed, Oct 25, 2000 at 10:49:52PM +0200, Trond Myklebust wrote:
> This should already be done IIRC. At least nfsd_open() always sets
> O_LARGEFILE.
Yes, that is just working right.
> we should be returning EOVERFLOW rather than EBIG.
Right.
2.4.0-test10-pre4 is also buggy because it doesn't c
On Wed, Oct 25, 2000 at 11:25:14PM +0300, Matti Aarnio wrote:
> The NFSv3 SERVER (for which Andrea made his patch)
> actually MUST open local files with O_LARGEFILE
> flag set. (Otherwise e.g. EXT2 may reject the open.)
Exactly, that is the code-sharing implementation detail I
On Wed, Oct 25, 2000 at 09:34:49PM +0200, Trond Myklebust wrote:
> All NFSv3 operations are 64-bit and LFS-compliant. There's therefore
> no need for an O_LARGEFILE flag.
I don't understand what you mean, sorry.
Userspace programs must open with O_LARGEFILE to go over 2G. This is true
regardless
> Matti Aarnio <[EMAIL PROTECTED]> writes:
> The NFSv3 SERVER (for which Andrea made his patch) actually
> MUST open local files with O_LARGEFILE flag set. (Otherwise
> e.g. EXT2 may reject the open.)
This should already be done IIRC. At least nfsd_open() always sets
O_LAR
On Wed, Oct 25, 2000 at 09:34:49PM +0200, Trond Myklebust wrote:
> > " " == Matti Aarnio <[EMAIL PROTECTED]> writes:
> >When the NFS server does file open, does it do it with
> >O_LARGEFILE, or not ? Is there a standardized way to pass
> >that flag over NFSv3 ?
>
>
> " " == Matti Aarnio <[EMAIL PROTECTED]> writes:
>When the NFS server does file open, does it do it with
>O_LARGEFILE, or not ? Is there a standardized way to pass
>that flag over NFSv3 ?
All NFSv3 operations are 64-bit and LFS-compliant. There's therefore
no nee
On Wed, Oct 25, 2000 at 06:26:25PM +0300, Matti Aarnio wrote:
> On Wed, Oct 25, 2000 at 03:57:39PM +0200, Andrea Arcangeli wrote:
> > This bug causes nfsd kernel based server to wrongly truncate files
> > while using offsets over 4G. With patch applied it starts to work right.
>
>Is it correc
On Wed, Oct 25, 2000 at 03:57:39PM +0200, Andrea Arcangeli wrote:
> This bug causes nfsd kernel based server to wrongly truncate files
> while using offsets over 4G. With patch applied it starts to work right.
Is it correct to limit it in anyway at the server ?
Let the CLIENT to handle the
This bug causes nfsd kernel based server to wrongly truncate files while using
offsets over 4G. With patch applied it starts to work right.
~(size_t) 0 is wrong too because size_t on IA32 is mere 32bit and as second
because ~0 is negative I think also causing a remote security issue since users
c
13 matches
Mail list logo
