Am 09.07.2006 um 23:32 schrieb Paul Eggert:
Georg Schwarz <[EMAIL PROTECTED]> writes:
hmmm, whose fault is it?
Apparently your kernel or file system has a serious bug. As your
private email to me demonstrated, if "empty" is an empty directory and
"d" is a directory, then the system call rename("d", "empty") does not
decrement the link count of ".", and this corrupts the file system.
What sort of file system are the files on?
normal SCSI hard disk, standard file system, i.e. efs (no XFS).
I assume IRIX 5.3 has a 'rename' system call, and that 'rename' is not
emulated by lower-level calls? You should be able to check this by
using "par -isSS mv -fT empty d".
OK:
lorenz 22% par -isSS /var/tmp/coreutils-5.97/src/mv -fT a b
0mS par( 753): was sent signal SIGUSR1
2mS par( 753): END-pause() errno = 4 (Interrupted system
call)
2mS par( 753): received signal SIGUSR1
2mS par( 753): sigreturn(0x7fffaa98) OK
2mS mv( 753): execve(/var/tmp/coreutils-5.97/src/mv,
0x7fffaf3c, 0x7fffaf50) OK
55mS mv( 753): open(/lib/rld, O_RDONLY, 04) = 3
55mS mv( 753): read(3, <7f 45 4c 46 01 02 01 00 00 00 00
00 00 00 00 00>..., 52) = 52
55mS mv( 753): lseek(3, 52, SEEK_SET) = 52
55mS mv( 753): read(3, <70 00 00 00 00 00 00 a0 0f b6 00
a0 0f b6 00 a0>..., 96) = 96
55mS mv( 753): elfmap(3, 0x7fffa24c, 2) = 0xfb60000
55mS mv( 753): close(3) OK
56mS mv( 753): getpagesize() = 4096
56mS mv( 753): getpagesize() = 4096
56mS mv( 753): open(/dev/zero, O_RDONLY, 01757000370) = 3
57mS mv( 753): mmap(0xfbc1000, 28672, PROT_WRITE|
PROT_READ, MAP_PRIVATE, 3, 0) = 0xfbc1000
57mS mv( 753): close(3) OK
102mS mv( 753): open(/usr/local/pkg/lib/libintl.so.4,
O_RDONLY, 05) = 3
180mS mv( 753): read(3, <7f 45 4c 46 01 02 01 00 00 00 00
00 00 00 00 00>..., 1024) = 1024
202mS mv( 753): elfmap(3, 0xfbc38c8, 2) = 0x5ffe0000
202mS mv( 753): close(3) OK
203mS mv( 753): open(/usr/local/pkg/lib/libiconv.so.3,
O_RDONLY, 05) = 3
261mS mv( 753): read(3, <7f 45 4c 46 01 02 01 00 00 00 00
00 00 00 00 00>..., 1024) = 1024
291mS mv( 753): elfmap(3, 0xfbc5500, 2) = 0x5fef0000
292mS mv( 753): close(3) OK
293mS mv( 753): open(/dev/zero, O_RDONLY, 01757000370) = 3
294mS mv( 753): mmap(0xfbc8000, 32768, PROT_WRITE|
PROT_READ, MAP_PRIVATE, 3, 0) = 0xfbc8000
294mS mv( 753): close(3) OK
294mS mv( 753): open(/usr/local/pkg/lib/libgen.so,
O_RDONLY, 05) errno = 2 (No such file or directory)
295mS mv( 753): open(/usr/lib/libgen.so, O_RDONLY, 05) = 3
296mS mv( 753): read(3, <7f 45 4c 46 01 02 01 00 00 00 00
00 00 00 00 00>..., 1024) = 1024
296mS mv( 753): elfmap(3, 0xfbc8968, 2) = 0xf9a0000
296mS mv( 753): close(3) OK
297mS mv( 753): getpid() = 753 ppid=752
355mS mv( 753): syssgi(SGI_TOSSTSAVE) OK
371mS mv( 753): getpagesize() = 4096
371mS mv( 753): brk(0x10005000) OK
397mS mv( 753): getuid() = 1110 euid=1110
397mS mv( 753): ioctl(0, TCGETA, 0x7fffada0) = 0
397mS mv( 753): umask(0) = 022
438mS mv( 753): lstat(a, 0x7fffacb8) OK
438mS mv( 753): lstat(b, 0x7fffac30) OK
439mS mv( 753): rename(a, b) OK
494mS mv( 753): prctl(PR_GETNSHARE) = 0
527mS mv( 753): close(1) OK
527mS mv( 753): exit(0)
exit : 1 times
read : 5 times
open : 7 times
close : 7 times
brk : 1 times
lseek : 1 times
getpid : 1 times
getuid : 1 times
syssgi : 5 times
ioctl : 1 times
sysmp : 3 times
execve : 1 times
umask : 1 times
sigreturn : 1 times
rename : 1 times
prctl : 1 times
mmap : 2 times
lxstat : 2 times
so looks like there is rename being used. BTW, I didn't know of that
par command before. Can be pretty handy I think.
According to the man page of rename, it *should* be able to handle
that case.
I came across the following
http://stuff.mit.edu/afs/athena/astaff/project/sgidev/docs/Fixed-in-6.2
(look for bug 322938; which here refers to xfs).
I am wondering whether SGI still maintains a publicly readable bug
tracking system. I'd be hoping to find a reference whether that issue
also applied to efs and where it was fixed.
I also found http://www-uxsup.csx.cam.ac.uk/pub/public_patches/SGI/
6.1/patch1674.relnotes
According to this description the bug is not limited to xfs.
According to http://www-uxsup.csx.cam.ac.uk/pub/public_patches/SGI/
5.3/patch1409.relnotes this patch also exists for IRIX 5.3.
Patch 1409 is still available, but probably it will apply only on the
XFS version of IRIX 5.3.
Changing the subject slightly:
<https://support.sgi.com/content_request/8277/index.html> says
SGI last released IRIX 5.3 in May 1996 and stopped supporting it in
January 2002. That same reference says that SGI has expired all IRIX
releases other than the current one, 6.5. So there is no point in
your reporting this bug to SGI unless the bug also occurs in IRIX 6.5.
I didn't expect so :-)
Are there old patch sets from SGI for IRIX 5.3 that you could apply to
your system? Perhaps they might fix the problem.
I've applied already every applicable patch I could get hold of. You
can still get quite some of them at ftp://ftp.sgi.com/support/Patches/
5.3.
I also got the Y2K patches from ftp://ftp.mayn.de/pub/
really_old_stuff/irix/oldstuff/
Is it still important that new GNU utilities run on this old system,
or are you just trying to help out by using IRIX 5.3 as a porting
target to debug the coreutils installation procedure? If the latter,
then I suspect it's not worth the trouble: we typically are worried
about porting only to systems that actively employ recent coreutils
apps in practical use.
the IRIX machine is not mission critical to me :-)
It's a toy, not a production machine. I use it for testing code on
akward systems :-)
Sometimes problems showing up on such systems can be relevant for
more modern ones as well.
--
Georg Schwarz http://home.pages.de/~schwarz/
[EMAIL PROTECTED] +49 178 8545053
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
