Michael Stone [EMAIL PROTECTED] wrote:
Have you seen this bug report?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329451
Yes.
I've just dealt with it on the upstream trunk:
2006-06-03 Jim Meyering [EMAIL PROTECTED]
Make `cp --link --no-dereference' work also on systems where
Wiktor Wandachowicz [EMAIL PROTECTED] wrote:
2006/5/27, Jim Meyering [EMAIL PROTECTED]:
Many packages like the coreutils use the .po files available via
the Translation Project. In this case, I updated all .po files
just prior to release of 5.96. At that time, the latest pl.po
file was
On 6/2/06, Ian Jackson [EMAIL PROTECTED] wrote:
There are I think two approaches to this problem:
* find a list of mountpoints in some system-specific way
for each one stat mountpoint/..
I would strongly advise against this option. Briefly, findutils did
this for other reasons (as part
Jim Meyering writes (Re: Bug#369822: ls -i stats unnecessarily):
So at least Solaris 8 and some glibc are affected.
Err, what's glibc got to do with it ? This behaviour is expected: if
you readdir the directory containing a mountpoint, you get the inode
number of the directory in the underlying
Ian Jackson writes (Re: Bug#369822: ls -i stats unnecessarily):
There are I think two approaches to this problem:
* find a list of mountpoints in some system-specific way
for each one stat mountpoint/..
compare device and inode with those of the directory we're readdir'ing
* provide
[EMAIL PROTECTED] test]# uname /?
uname: ¶îÍâµÄ²Ù×÷Êý ¡°/a¡±
Çë³¢ÊÔÖ´ÐС°uname --help¡±À´»ñÈ¡¸ü¶àÐÅÏ¢¡£
[EMAIL PROTECTED] test]# uname /a
uname: ¶îÍâµÄ²Ù×÷Êý ¡°/a¡±
Çë³¢ÊÔÖ´ÐС°uname --help¡±À´»ñÈ¡¸ü¶àÐÅÏ¢¡£
[EMAIL PROTECTED] test]# uname --help
Ó÷¨£ºuname [Ñ¡Ïî]...
Print certain system
I do not have the gb2312 charset in which your message was encoded
installed on my system. Apologies if certain characters did not
encode properly. Please consider using a UTF-8 encoding for portable
message interchange.
[EMAIL PROTECTED] test]# uname /?
uname: ??/a??
I can understand why readdir might have the behavior that you
describe: it might be more efficient internally. But that doesn't
make it correct, or even expected. It's a bug in readdir.
I agree - readdir should ALWAYS match stat, even in the face of
mount points, if it is going to provide
