On Mon, May 13, 2002 at 05:45:21PM -0400, Roland McGrath wrote: > There is no need to lock the node and indeed it is bad to do so, as you > see. (There is no need to lock because the file port never changes while > the node lives.)
... and exec does it's own attempt at synchronization, so that it sees a consistent file content. Yeah, locking it was bogus. I am wondering if for the other calls locking is also unnecessary (although not harmful) as we are only passing through and the locking of the "real" node at the end of the chain will make sure nothing bad happens. > I also fixed it not to use MACH_MSG_TYPE_MOVE_SEND, which > is not safe in any interruptible Hurd RPC. I don't understand this in the context of fakeroot. We are only forwarding a message, and never try again. It seems to be the responsibility of the caller to make sure he still has send rights to repeat the file_exec call. What am I missing? > Please investigate the latter problem. Firstly, (assuming non-suid > scripts) Yes, non-suid scripts. I wanted to spare me the disappointment of running a program that would fail in both cases, with and without overriding file_exec :) > it should find a name instead of using the /dev/fd kludge unless > argv[0] has a stupid value. argv[0] is fine. I run bashbug. It found bashbug in /usr/bin/bashbug. But the io_identity is different for the FILE passed to file_exec, and NAME_FILE looked up in the exec server. I have not found out yet what the reason is, I guess we are talking to different servers here when doing the lookup. But because we talk to the real filesystem when forwarding the message, this would mean that we talk to the fakeroot server when exec looks up /usr/bin/bashbug. Does this make sense? > But even with that broken, the /dev/fd/3 ought > to work (unless the script itself closes the descriptor before using it or > something). Well, all scripts fail the same way, nothing is closing it. I have not come further with this one. Not sure what I will try next. Is there an easier way to find out how PIDs in different Hurds map to each other than listing all with ps -A and matching up the statistics? > > There is another problem with fakeroot, and that is chmod. It doesn't work > > at all :) I always get EOPNOTSUPP. > > I didn't pay close enough attention to what netfs does (or follow the nfs > example closely), and that comment from netfs.h is not entirely clear on > what the function has to do. It gets called with no S_IFMT bits set when > not changing. I fixed fakeroot so it should work right. Darn, forgot to test this! Debugging the above hooked me up. Will do this next round. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
