Re: Bug#369822: ls -i stats unnecessarily

[Eric Blake]

> 
> 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 d_ino.  Even cygwin developers
took great care in their upcoming 1.5.20 release to ensure that
mount points are handled correctly, such that readdir reports
the same value that stat will provide.

Is there an easy configure or runtime test we can do to detect
buggy readdir implementations, and always do stat on those
platforms?

-- 
Eric Blake


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug#369822: ls -i stats unnecessarily

[Paul Eggert]

Ian Jackson <[EMAIL PROTECTED]> writes:

> This behaviour is expected: if you readdir the directory containing
> a mountpoint, you get the inode number of the directory in the
> underlying filesystem;

That's not the behavior that I expected.  Also, it's not useful
behavior--at least, it's not useful for the vast majority of
real-world applications.  In contrast, it is useful for 'ls -i' to
print the inode number of the root of the mounted file system, for
'find -inum' to use that inode number, and so forth.

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.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

uname option handling problem (Re: bug)

[Bob Proulx]

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??
> uname --help??
> [EMAIL PROTECTED] test]# uname /a
> uname:  ??/a??
> uname --help??

In my locale (en_US.UTF-8) the english version of the message says:

  ./src/coreutils/src/uname: extra operand `/?'
  Try `./src/coreutils/src/uname --help' for more information.

  ./src/coreutils/src/uname: extra operand `/a'
  Try `./src/coreutils/src/uname --help' for more information.

This is because the '/' character is not an option designator on GNU
or Unix systems.  There you would use the '-' option disignator.

Try this:

  uname -a

And you should see the output result that you desire.

> [EMAIL PROTECTED] test]# uname --help
> ??uname []...
> Print certain system information.  With no OPTION, same as -s.
> 
>   -a, --allprint all information, in the following order,
>  except omit -p and -i if unknown:
>   -s, --kernel-nameprint the kernel name
>   -n, --nodename   print the network node hostname
>   -r, --kernel-release print the kernel release
>   -v, --kernel-version print the kernel version
>   -m, --machineprint the machine hardware name
>   -p, --processor  print the processor type or "unknown"
>   -i, --hardware-platform  print the hardware platform or "unknown"
>   -o, --operating-system   print the operating system
>   --help 
>   --version  ??
> 
>   ??

As you can see all of the options listed there start with a '-'
character.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

bug

[黄小猛]

[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 information.  With no OPTION, same as -s.

  -a, --allprint all information, in the following order,
 except omit -p and -i if unknown:
  -s, --kernel-nameprint the kernel name
  -n, --nodename   print the network node hostname
  -r, --kernel-release print the kernel release
  -v, --kernel-version print the kernel version
  -m, --machineprint the machine hardware name
  -p, --processor  print the processor type or "unknown"
  -i, --hardware-platform  print the hardware platform or "unknown"
  -o, --operating-system   print the operating system
  --help ÏÔʾ´Ë°ïÖúÐÅÏ¢²¢À뿪
  --version  ÏÔʾ°æ±¾ÐÅÏ¢²¢À뿪

ÇëÏò  ±¨¸æ´íÎó¡£





___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug#369822: ls -i stats unnecessarily

[Ian Jackson]

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 an option to allow the user to specify that they don't
>mind the inode numbers of mountpoints being wrong

Someone has just pointed out to me that no matter what you do, you
don't get the dev for the covering filesystem.  So returning the inum
of the root of the covering fs is definitely wrong and should never be
done.

Think about it: if you ls -i anywhere near a mount point you're
_inevitably_ going to get useless data because the output doesn't
contain devs.  So anyone who does ls -i usefully must know that there
are no mountpoints and this whole issue can be ignored.

Ian.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug#369822: ls -i stats unnecessarily

[Ian Jackson]

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 filesystem; if you then stat
the mountpoint, you get the inode number of the root of the
filesystem mounted on top.

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 an option to allow the user to specify that they don't
   mind the inode numbers of mountpoints being wrong

The 2nd is easier and certainly less fragile, and since this no-stat
optimisation is only necessary in some specialised applications (of
which I happen to have an application where it's absolutely essential
because statting each file takes far far too long), it's not that
unreasonable to demand a special option.

> unless I find a better approach, I'll turn off this optimization
> by default, and add an option to turn it back on.

Right.

Ian.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug#369822: ls -i stats unnecessarily

[James Youngman]

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 of its symlink race condition paranoia
checking).  It makes the program hang is the system is a client of a
dead NFS server, even if the user is not using "ls" to work with
filesystems on that server.

There were many bug reports.  I ended up finding an alternative way to
solve the problem.

If I was trying to diagnose a problem on a client of a dead NFS
server, I would expect "ls" to _help_ in the diagnosis, not be
affected by the problem too.  For a fundamental tool like ls, it is
reasonable to favour robusness over performance.

I suppose one could have a fast /bin/ls and a robust /sbin/ls, but
that would I think only lead to people including the wrong binary in
rescue disks (having said this though of course that special niche is
often filled by busybox anyway).

James.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils-5.96 has broken pl.po translation

[Jim Meyering]

"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 against coreutils-5.95.  Post-release of coreutils-5.96,
>> I see there is now a newer pl.po:
>>
>>   http://www.iro.umontreal.ca/translation/teams/PO/pl/coreutils-5.96.pl.po
>>
>> Please see if that solves the problem.
>
> Thanks for the link. I'm sorry to report that the problem persists,
> for 5.96, 5.95 and 5.94 versions of the respective .po files. The last
> working version appears to be for 5.93.
>
>> If not, please report the problem to the people who can fix it.
>
> In that case I guess I'll try to bounce the problem there.
> Thanks again for pointers.

Thanks for the update.
I still don't see a new version at the above URL.
Do you know if a new version has been submitted?


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: posix & links

[Jim Meyering]

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 the
link system call cannot create a hard link to a symbolic link.
* src/copy.c (copy_internal) [LINK_FOLLOWS_SYMLINKS]: Don't use
the link syscall on a symlink when it would do the wrong thing.
Based on the patch by Aurelien Jarno: 
* tests/cp/link-no-deref: New file/test for the above.
* tests/cp/Makefile.am (TESTS): Add link-no-deref.
* NEWS: Mention the change (doesn't affect Linux).

Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.199
retrieving revision 1.200
diff -u -p -u -r1.199 -r1.200
--- src/copy.c  11 May 2006 08:55:04 -  1.199
+++ src/copy.c  3 Jun 2006 09:04:22 -   1.200
@@ -1594,7 +1594,22 @@ copy_internal (char const *src_name, cha
}
 }
 #endif
-  else if (x->hard_link)
+
+  else if (x->hard_link
+#ifdef LINK_FOLLOWS_SYMLINKS
+  /* A POSIX-conforming link syscall dereferences a symlink, yet cp,
+ invoked with `--link --no-dereference', should not.  Thus, with
+ a POSIX-conforming link system call, we can't use link() here,
+ since that would create a hard link to the referent (effectively
+ dereferencing the symlink), rather than to the symlink itself.
+ We can approximate the desired behavior by skipping this hard-link
+ creating block and instead copying the symlink, via the `S_ISLNK'-
+ copying code below.
+ When link operates on the symlinks themselves, we use this block
+ and just call link().  */
+  && !(S_ISLNK (src_mode) && x->dereference == DEREF_NEVER)
+#endif
+  )
 {
   preserve_metadata = false;
   if (link (src_name, dst_name))


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils