[Top][All Lists]

[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


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 "", 
    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
#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

I am not sure why it gets stuck.  Should netfs_attempt_lookup in fakeroot be
special cased?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]