Re: Bug#369822: ls -i stats unnecessarily
Ian Jackson [EMAIL PROTECTED] writes: the inum on its own isn't useful if you don't know either (a) there are no mountpoints here or (b) exactly where the mountpoints are. No, it can be useful. For example, suppose you have the inum Fi of some other file F, and want to know whether this directory entry could be that of F. If readdir returns d_ino == Ri, and if Ri != Fi, then you know that it can't possibly be a match. This sort of optimization can be quite useful to avoid a stat, but it doesn't work if d_ino might be junk from an underlying file system. On operating systems where d_ino might be junk at mount points, we have to suppress optimizations like this. On operating systems where d_ino is reliable at mount points, our code can run faster. If you know it's a mounted filesystem, you can ask ls -id /mount/point/. Sure, but I shouldn't have to ask pretty please, can I get the correct inode number? readdir should give me the correct inode number in the first place. Eg, inum=`ls -id /unexpected/mount/point/.` find / -xdev -inum $inum isn't going to work properly ! Sure it works properly. Any file in the subsidiary file system will have an inode number that is allocated independently of inode numbers of files in the root file system. If I changed the example to this: inum=`ls -id /unexpected/mount/point/somefile` find / -xdev -inum $inum then that works properly, in that it attempts to find a file in the root file system whose inode number is the same as the inode number of somefile. Your example should work the same way, with . rather than somefile. Anyway, I just now checked Posix on this and found that it allows implementations of readdir to return a random value for d_ino! Wow. I filed an Aardvark about it here, which you are welcome to follow up: http://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-review-lid=2070 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: workaround for problem with VPATH-based builds on Solaris
Paul Eggert [EMAIL PROTECTED] wrote: Jim, should I also install this patch on the 5.9x branch of coreutils? 2006-06-05 Paul Eggert [EMAIL PROTECTED] Fix problems when building with Solaris/SVR4/etc. make, which uses a different and somewhat bogus implementation of VPATH. In the Yes, please. Thanks for tracking that down! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
workaround for problem with VPATH-based builds on Solaris
This message is following up on two threads.
In http://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00178.html
Ralf Wildenhues reported a serious problem with a VPATH-based build
for coreutils using Solaris 'make', in which the build causes a fork
bomb that can bring the system and/or user to its knees.
In http://lists.gnu.org/archive/html/autoconf-patches/2006-06/msg00018.html
I responded by installing a patch into Autoconf so that it now
recommends VPATH-based builds only for GNU make.
I eventually tracked the coreutils bug down to the following problem.
With Automake-generated make files, you can't have a test whose name
is 'test', if you want to have VPATH builds that work with
Automake-generated makefiles on Solaris. Nor can you have a test
whose name contains any of several other standard words like 'echo'.
This is because the VPATH builds mess up on Solaris, by prepending
.../ to all instances of these words, even when this is not intended.
I installed the following patch into the coreutils main branch. It
works around the immediate problem. But this is still a minefield,
and I can't recommend using Solaris make for VPATH builds..
I'm CC'ing this to bug-automake because it's not immediately obvious
that you can't put 'TESTS = test echo' etc. in Makefile.am, if you
want your code to work with VPATH builds and Solaris make. I presume
the problem extends to variables other than TESTS.
Perhaps Automake should follow Autoconf's lead, and start recommending
VPATH builds only for GNU make? If so, I could prepare a patch to the
Automake documentation along these lines.
Jim, should I also install this patch on the 5.9x branch of coreutils?
2006-06-05 Paul Eggert [EMAIL PROTECTED]
Fix problems when building with Solaris/SVR4/etc. make, which uses a
different and somewhat bogus implementation of VPATH. In the
directory tests/misc, rename tests whose names might appear in the
Automake-generated rules. For example, we can't use a test named
'test', since Automake generates a rule that contains the text
if test -f ./$$tst; ..., and this might expand to something like
if ../../../coreutils-6.0/tests/misc/test -f ./$$test; ...,
which executes the 'test' script rather than the 'test' command.
* tests/misc/false-status: Renamed from tests/misc/false.
* tests/misc/pwd-long: Renamed from tests/misc/pwd.
* tests/misc/sort-merge: Renamed from tests/misc/sort.
($prog): Set to 'sort' rather than to $PROG.
* tests/misc/test-diag: Renamed from tests/misc/test.
* tests/misc/Makefile.am (PROG): Take the basename of $$tst,
in case Solaris make has prepended the directory.
(TESTS): Adjust to above renamings.
* tests/misc/expand: Don't assign to PROG; no longer needed
now that Makefile.am sets PROG to the basename.
* tests/misc/fold: Likewise.
Index: tests/misc/Makefile.am
===
RCS file: /fetish/cu/tests/misc/Makefile.am,v
retrieving revision 1.37
diff -p -u -r1.37 Makefile.am
--- tests/misc/Makefile.am 26 Mar 2006 11:48:19 - 1.37
+++ tests/misc/Makefile.am 5 Jun 2006 20:02:06 -
@@ -9,7 +9,13 @@ TESTS_ENVIRONMENT = \
PERL=$(PERL) \
BUILD_SRC_DIR=`pwd`/../../src \
PATH=`pwd`/../../src$(PATH_SEPARATOR)$$PATH \
- PROG=$$tst
+ PROG=`../../src/basename -- $$tst`
+
+# Do not choose a name that is a shell keyword like 'if', or a
+# commonly-used utility like 'cat' or 'test', as the name of a test.
+# Otherwise, VPATH builds will fail on hosts like Solaris, since they
+# will expand 'if test ...' to 'if .../test ...', and the '.../test'
+# will execute the test script rather than the standard utility.
TESTS = \
base64 \
@@ -20,7 +26,7 @@ TESTS = \
date-sec \
dirname \
expand \
- false \
+ false-status \
fold \
head-c \
head-elide-tail \
@@ -33,12 +39,12 @@ TESTS = \
pathchk1 \
printf \
printf-hex \
- pwd \
+ pwd-long \
sha224sum \
sha256sum \
sha384sum \
sha512sum \
- sort \
+ sort-merge \
sort-rand \
split-a \
split-fail \
@@ -46,5 +52,5 @@ TESTS = \
stat-fmt \
stat-printf \
tac-continue \
- test \
+ test-diag \
tty-eof
Index: tests/misc/expand
===
RCS file: /fetish/cu/tests/misc/expand,v
retrieving revision 1.2
diff -p -u -r1.2 expand
--- tests/misc/expand 20 Apr 2005 07:54:54 - 1.2
+++ tests/misc/expand 5 Jun 2006 20:02:06 -
@@ -18,8 +18,6 @@ use strict;
(my $program_name = $0) =~ s|.*/||;
-$ENV{PROG} = 'expand';
-
# Turn off localization of executable's ouput.
@ENV{qw(LANGUAGE LANG LC_ALL)} = ('C') x 3;
Index: tests/misc/fold
===
RCS file: /fetish/cu/tests/misc/fold,v
retrieving revision 1.3
diff -p -u -r1.3 fold
--- tests/misc/fold 20
Re: Bug#369822: ls -i stats unnecessarily
Paul Eggert writes (Re: Bug#369822: ls -i stats unnecessarily): 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. If you know it's a mounted filesystem, you can ask ls -id /mount/point/. instead of ls -id /mount/point If you don't know it's a mounted filesystem then the inode number of the mounted filesystem is useless to you. Eg, inum=`ls -id /unexpected/mount/point/.` find / -xdev -inum $inum isn't going to work properly ! 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. You might say that it's a deficiency in the readdir interface, as well as in ls -i, etc. etc., that it doesn't provide the dev as well as the inum. But however you look at it, the inum on its own isn't useful if you don't know either (a) there are no mountpoints here or (b) exactly where the mountpoints are. In case (a) you don't care about the distinction; in case (b) you can compensate with stat. Ian. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: posix links
Jim Meyering wrote: 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: http://bugs.debian.org/329451 * 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). I have just test the CVS version, and it works well on GNU/kFreeBSD. Thanks a lot! -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: workaround for problem with VPATH-based builds on Solaris
Jim, should I also install this patch on the 5.9x branch of coreutils? 2006-06-05 Paul Eggert [EMAIL PROTECTED] Fix problems when building with Solaris/SVR4/etc. make, which uses a different and somewhat bogus implementation of VPATH. In the Yes, please. Thanks for tracking that down! OK, done. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
