Hello,
we experienced some change in the directory sort order. We installed a new
server with kernel 2.6.18. While testing, an old (but important) application
won't correctly show a directory selection window (is there a name for such a
thing?) when changing to a NFS (version2) mounted directory.
Further investigations showed, that up to kernel 2.6.11 a "ls -f" gave a
unsorted directory listing, but beginning with "." and "..".
Newer kernel (I checked 2.6.18 and 2.6.25) have the "." and ".." somewhere else
in the "ls -f" output.
The same sort order can be seen using nfsV2 with "tcpdump".
I think this the reason for our application to behave weird.
My question: is this a bug, or a feature? I could not find anything about that
anywhere...
Does anybody have an idea, how I can fix this? Unfortunately, our application
can not be changed.
Many thanks in advance & best regards,
Oliver Soltys
****************************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance on
it, is prohibited.
E-mail messages are not necessarily secure. Renesas does not accept
responsibility for any changes made to this message after it was sent.
Please note that this email message has been swept by Renesas for
the presence of computer viruses.
Renesas Semiconductor Europe (Landshut) GmbH
Jenaer Strasse 1, 84034 Landshut
Tel.: +49-(0)871-684-0, Fax: +49-(0)871-684-150
http://www.rsel.renesas.com
GESCHAEFTSFUEHRER: Dipl.-Ing. YOSHIHARU KAKUI
GESCHAEFTSFUEHRER: Dipl.-Phys. STEFAN SAUER
Registergericht Landshut HRB 1464
Ust-ldNr.: DE 128953054 Steuer-Nr.: 132/136/30347
HypoVereinsbank, Landshut, Kto.-Nr. 3704 700 (BLZ 743 200 73)
Mizuho Corporate Bank (Germany) AG, Frankfurt, Kto.-Nr. 200 733 (BLZ 503 308 00)
****************************************************************************
Oliver Soltys wrote:
> My question: is this a bug, or a feature? I could not find anything about that
> anywhere...
>
> Does anybody have an idea, how I can fix this? Unfortunately, our application
> can not be changed.
No Unix-like system makes any guarantee about the order of '.' and '..'
with respect to other directory entries. They've often appeared first
as an implementation side-effect, but that's highly system and
filesystem dependent.
If you can't modify the app, you might consider some LD_PRELOAD library
to replace readdir with something that sorts the results in the order
your app expects. There's already examples of that kind of thing to
sort the results by inode.
J
On Tue, Jul 29, 2008 at 7:53 AM, Jeremy Fitzhardinge <[email protected]> wrote:
> Oliver Soltys wrote:
>>
>> My question: is this a bug, or a feature? I could not find anything about
>> that
>> anywhere...
>>
>> Does anybody have an idea, how I can fix this? Unfortunately, our
>> application
>> can not be changed.
>
> No Unix-like system makes any guarantee about the order of '.' and '..' with
> respect to other directory entries. They've often appeared first as an
> implementation side-effect, but that's highly system and filesystem
> dependent.
>
> If you can't modify the app, you might consider some LD_PRELOAD library to
> replace readdir with something that sorts the results in the order your app
> expects. There's already examples of that kind of thing to sort the results
> by inode.
That's a good idea, though based on his description it's even easier.
The LD_PRELOAD just needs to artificially introduce . and .., at the
beginning and toss them out once it hits them in the list. No sorting
required.
Ray Lee wrote:
> On Tue, Jul 29, 2008 at 7:53 AM, Jeremy Fitzhardinge <[email protected]> wrote:
>
>>Oliver Soltys wrote:
>>
>>>My question: is this a bug, or a feature? I could not find anything about
>>>that
>>>anywhere...
>>>
>>>Does anybody have an idea, how I can fix this? Unfortunately, our
>>>application
>>>can not be changed.
>>
>>No Unix-like system makes any guarantee about the order of '.' and '..' with
>>respect to other directory entries. They've often appeared first as an
>>implementation side-effect, but that's highly system and filesystem
>>dependent.
Alas, this implementation side-effect dates back to v6[1], and is so
depended upon that even CD filesystems, which are by no means Unix-like,
contain dummy "." and ".." entries[2].
I'd recommend either reproducing it or starting a project
to hunt down and kill all the programs which assume it (;-))
--dave
[1. I helped on the DPS-6 upgrade from v6 to v7, and it was a (dis)feature then]
[2. Andy Tannenbaum "Modern Operating Systems", 2nd Edition]
> That's a good idea, though based on his description it's even easier.
> The LD_PRELOAD just needs to artificially introduce . and .., at the
> beginning and toss them out once it hits them in the list. No sorting
> required.
--
David Collier-Brown | Always do right. This will gratify
Sun Microsystems, Toronto | some people and astonish the rest
[email protected] | -- Mark Twain
(905) 943-1983, cell: (647) 833-9377, (800) 555-9786 x56583
bridge: (877) 385-4099 code: 506 9191#
David Collier-Brown wrote:
> Alas, this implementation side-effect dates back to v6[1], and is so
> depended upon that even CD filesystems, which are by no means Unix-like,
> contain dummy "." and ".." entries[2].
Er, no, I wouldn't call '.' and '..' implementation side-effects in
themselves. They're one of the particularly clever parts of the
filesystem/namespace design. I would agree that the specific
implementation using "link" and "unlink" was a bit of a hack, and adding
proper "mkdir" and "rmdir" made the world a better place.
> I'd recommend either reproducing it or starting a project
> to hunt down and kill all the programs which assume it (;-))
Well, '.' and '..' are guaranteed to be somewhere in a (linked)
directory, so all filesystems are required to make sure they exist
somewhere, and programs which expect them to exist are perfectly within
their rights. But not necessarily the first two entries.
J
Ray Lee wrote:
> That's a good idea, though based on his description it's even easier.
> The LD_PRELOAD just needs to artificially introduce . and .., at the
> beginning and toss them out once it hits them in the list. No sorting
> required.
>
You'd have to be careful with respect to seekdir/telldir, but that may
not matter if its just an app-specific hack.
J