[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fakeroot problem
From: |
Marcus Brinkmann |
Subject: |
fakeroot problem |
Date: |
Sun, 5 May 2002 14:33:22 -0400 |
User-agent: |
Mutt/1.3.25i |
Hi,
I have a small fix for settrans (in the argp parser, there is a break
where should be a return0, the break only breaks out of the while,
not out of the switch), which I will commit later.
Having fixed that, it still doesn't work. Up to the chdir("/"),
everything goes ok. But then it fails to chdir("/") with the error message
"Is a directory" (EISDIR), which proves that complex computer systems
like the Hurd not only develop artificial intelligence, but also some
strange kind of humor.
I traced it to __dir_lookup, which is invoked with the argument:
#0 __dir_lookup (start_dir=126, file_name=0x11ff9b2 ".", flags=0, mode=0,
do_retry=0x11ff538, retry_name=0x11ff540 "", result=0x11ff98c)
at ../mach/mach/mig_support.h:73
The start_dir port goes from settrans to fakeroot (the translator to
set) port 31.
Then I thought it is probably fakeroot, and yes, it does not work as
expected. I did a settrans foo /hurd/fakeroot, and although "ls foo"
works fine, and I can change the ownership of foo/file, etc, changing
the directory doesn't work. "cd foo" hangs. This is the backtrace
in fakeroot:
#0 0x0108e8f1 in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:118
#1 0x011f388b in __dir_lookup (start_dir=32, file_name=0x128bf68 ".",
flags=71, mode=0, do_retry=0x128b8e4, retry_name=0x128b8ec "",
result=0x128bd38)
at /mnt/glibc/glibc-2.2.5/i386-gnu/obj/hurd/RPC_dir_lookup.c:187
#2 0x0107df39 in lookup_op.0 (startdir=32) at hurdlookup.c:59
#3 0x0107e50a in use_init_port.3 (which=0, operate=0x128b8cc)
at hurdlookup.c:282
#4 0x0107e034 in __hurd_file_name_lookup (use_init_port=0x128bd3c,
get_dtable_port=0x1091f98 <__getdport>, lookup=0x11f37e4 <__dir_lookup>,
file_name=0x128bf68 ".", flags=71, mode=0, result=0x128bd38)
at hurdlookup.c:94
#5 0x0107e56d in __file_name_lookup_under (startdir=32,
file_name=0x128bf68 ".", flags=71, mode=0) at
hurdlookup.c:284
#6 0x08049a02 in netfs_attempt_lookup (user=0x804be58, dir=0x804bc28,
name=0x128bf68 ".", np=0x128bdf8) at ../../trans/fakeroot.c:328
#7 0x010309a8 in netfs_S_dir_lookup () from /lib/libnetfs.so.0.2
#8 0x010338a7 in netfs_S_file_utimes () from /lib/libnetfs.so.0.2
#9 0x01034da9 in netfs_fs_server () from /lib/libnetfs.so.0.2
#10 0x01030636 in netfs_demuxer () from /lib/libnetfs.so.0.2
#11 0x0104bfd7 in ports_manage_port_operations_one_thread ()
from /lib/libports.so.0.2
etc...
I am not sure why it gets stuck. Should netfs_attempt_lookup in fakeroot be
special cased?
Thanks,
Marcus
- fakeroot problem,
Marcus Brinkmann <=
- Re: fakeroot problem, Roland McGrath, 2002/05/05
- Re: fakeroot problem, Thomas Bushnell, BSG, 2002/05/05
- Re: fakeroot problem, Marcus Brinkmann, 2002/05/05
- Re: fakeroot problem, Roland McGrath, 2002/05/05
- Re: fakeroot problem, Roland McGrath, 2002/05/05
- Re: fakeroot problem, Marcus Brinkmann, 2002/05/05
- Re: fakeroot problem, Marcus Brinkmann, 2002/05/10
- Re: fakeroot problem, Marcus Brinkmann, 2002/05/10
- Re: fakeroot problem, Marcus Brinkmann, 2002/05/11
- Re: fakeroot problem, Roland McGrath, 2002/05/11