From: Andreas Dilger <adilger@clusterfs.com>
To: Tigran Aivazian <tigran@veritas.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: olarge -- force O_LARGEFILE on app binaries.
Date: Mon, 14 Apr 2003 11:28:17 -0600 [thread overview]
Message-ID: <20030414112817.H26054@schatzie.adilger.int> (raw)
In-Reply-To: <Pine.LNX.4.44.0304141724130.3964-100000@einstein31.homenet>; from tigran@veritas.com on Mon, Apr 14, 2003 at 05:29:18PM +0100
On Apr 14, 2003 17:29 +0100, Tigran Aivazian wrote:
> On Mon, 14 Apr 2003, Andreas Dilger wrote:
> > I don't see how this helps you very much. So now, instead of the kernel
> > complaining with EFBIG and/or SIGXFSZ, your 32-bit size offset wraps in
> > the application.
>
> Good point, but, very _very_ luckily it does NOT happen in this case, i.e.
> with gs(1). I just verified every bit of output and it is correct both
> before and beyond the 2G boundary, all the way to 5.2G. But in general
> (i.e. for some other app) your comment is valid.
I suppose for applications that do only streaming I/O (and gs is one of those)
this O_LARGEFILE fix shouldn't cause any problem. Any applications which do
seeking, or otherwise use/store the file offset for any reason will likely
break. However, since they are still using the 32-bit syscalls, they will
likely just get EOVERFLOW and not die horribly (assuming they check the
return code).
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
prev parent reply other threads:[~2003-04-14 17:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 15:03 olarge -- force O_LARGEFILE on app binaries Tigran Aivazian
2003-04-14 16:19 ` Andreas Dilger
2003-04-14 16:29 ` Tigran Aivazian
2003-04-14 17:28 ` Andreas Dilger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030414112817.H26054@schatzie.adilger.int \
--to=adilger@clusterfs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tigran@veritas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.