From: William Taber <wtaber@rational.com>
To: linux-kernel@vger.kernel.org
Subject: fs/readdir.c:fillonedir() vs. fs/readdir.c:filldir()
Date: Fri, 19 Jan 2001 17:37:38 -0500 (EST) [thread overview]
Message-ID: <200101192237.RAA00039@cryolite.atria.com> (raw)
Hi folks,
In porting our file system to Linux, we discovered a discrepancy in the
old and new method of returning directory entries to programs. This
exists in 2.2.x and 2.4.x kernels (and maybe older ones too?)
fs/readdir.c:filldir(), used by most (?) programs, expects the
directory entry provided by the file system to have the d_offset field
set to the offset of the *current* entry, and it plays games to use the
next entry's offset to return to the user for the current directory
entry's d_offset field.
fs/readdir.c:fillonedir(), used by (apparently?) ancient
programs/libraries, expects the directory entry provided by the file
system to have the d_offset field set to what should be sent to the
user, i.e. the offset of the *next* entry.
These two are mutually incompatible interpretations of how to fill in
directory entries, and there's no way for the file system to tell which
one is going to be used when its file_ops->readdir() function is
invoked.
I would guess this is rarely a problem because fillonedir() is rarely
used, and it should be fixed to use the readdir results as expected by
filldir(). But I'm not sure it's possible to find/save enough state to
do this right, as the old readdir gets a single entry per syscall.
Perhaps the readdir interface to the file systems should expect the file
system to provide the proper d_offset field in each entry (holding the
offset of the following entry), then filldir() and sys_getdents() can
avoid all the mucking about with d_offset?
Will Taber
+---------------------------------------------------------------------+
| Will Taber |
| Software Engineer, CMBU E-mail wtaber@rational.com |
| Rational Software Corporation Phone: 781-676-2436 |
| 20 Maguire Road, Lexington, Mass. 02421 |
+---------------------------------------------------------------------+
-
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/
reply other threads:[~2001-01-19 22:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=200101192237.RAA00039@cryolite.atria.com \
--to=wtaber@rational.com \
--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
Powered by JetHome