From: Matthias Andree <matthias.andree@stud.uni-dortmund.de>
To: Linux-Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: 2.2.19 NFSv3 client breaks fdopen(3)
Date: Fri, 27 Apr 2001 01:30:28 +0200 [thread overview]
Message-ID: <20010427013028.A30741@emma1.emma.line.org> (raw)
In-Reply-To: <20010426192632.A18492@maggie.dt.e-technik.uni-dortmund.de> <15080.24119.524229.296133@charged.uio.no>
In-Reply-To: <15080.24119.524229.296133@charged.uio.no>; from trond.myklebust@fys.uio.no on Thu, Apr 26, 2001 at 19:43:19 +0200
On Thu, 26 Apr 2001, Trond Myklebust wrote:
> Please note that if glibc is checking this return value, it will still
> screw up if file->f_pos > 0x7fffffff, which can and does happen
> against certain servers (particularly IRIX).
Do servers have directories that are this large? It'd take quite some
files to get a directory itself (not counting its files) exceed 2 GB,
wouldn't it?
> As I've said before: it is a bug for glibc to be relying on seekdir if
> we want to support non-POSIX compliant filesystems under Linux.
There's no seekdir. No telldir. Just a "get ofile current position".
Meanwhile, I took a glance at fileops.c and iofdopen.c of the glibc
source RPM that SuSE 7.0 uses, there is no seekdir like stuff involved,
it's just that when glibc rolls the dice to get a FILE structure filled,
it gathers the current file position, since someone might have called
read before fdopen. I think that's legitimate.
Here's the excerpt, glibc-2.1/libio/fileops.c, ll. 255 ff.:
_IO_FILE *
_IO_new_file_attach (fp, fd)
_IO_FILE *fp;
int fd;
{
if (_IO_file_is_open (fp))
return NULL;
fp->_fileno = fd;
fp->_flags &= ~(_IO_NO_READS+_IO_NO_WRITES);
fp->_flags |= _IO_DELETE_DONT_CLOSE;
/* Get the current position of the file. */
/* We have to do that since that may be junk. */
fp->_offset = _IO_pos_BAD;
if (_IO_SEEKOFF (fp, (_IO_off64_t)0, _IO_seek_cur, _IOS_INPUT|_IOS_OUTPUT)
== _IO_pos_BAD && errno != ESPIPE)
return NULL;
return fp;
}
No seekdir. (would be pointless since seekdir does not return a value)
Not even telldir. Just plain fdopen. Is a plain fdopen supposed to fail
just because some clients don't understand the semantics some server
uses; not even considering who's fault it might be? Certainly not.
> --- /mnt/3/linux-2.2.19/fs/nfs/dir.c Sun Mar 25 08:37:38 2001
> +++ linux-2.2.19/fs/nfs/dir.c Thu Apr 5 14:37:59 2001
> @@ -454,6 +454,9 @@
Thanks, will try.
--
Matthias Andree
next prev parent reply other threads:[~2001-04-26 23:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-26 17:26 Matthias Andree
2001-04-26 17:43 ` Trond Myklebust
2001-04-26 23:30 ` Matthias Andree [this message]
2001-04-27 11:11 ` Trond Myklebust
2001-04-27 11:02 ` Matthias Andree
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=20010427013028.A30741@emma1.emma.line.org \
--to=matthias.andree@stud.uni-dortmund.de \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®