Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!rbj From: rbj@uunet.UU.NET (Root Boy Jim) Newsgroups: comp.unix.wizards Subject: Re: Wizard-level questions Message-ID: <120574@uunet.UU.NET> Date: 30 Jan 91 02:49:41 GMT References: <16048@sdcc6.ucsd.edu> <1991Jan26.142403.22812@mp.cs.niu.edu> Organization: UUNET Communications Services, Falls Church, VA Lines: 33 In article <1991Jan26.142403.22812@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <16048@sdcc6.ucsd.edu> cs163wcr@sdcc10.ucsd.edu (I support the U.N.) writes: >>[1] Can you access a file by its i-node number? Something like >> (for C code) FILE *iopen (int inode, char *mode) ? > > I hope not. Otherwise permissions on directories wouldn't do much. How about treating the block device as magic directory where all the "files" are really direct links to inodes. Subject to device permission. For further information see the paper "Devices as Directorys" in the Winter 2017 Usenix Conference Procedings. > I do think the system design would have been cleaner if you only accessed >by i-node number, and mapping filename to inode was done outside the kernel. >But I doubt that I have many supporters in this "keep the kernel small" view. But that would make the kernel smaller. I have often wanted to mknode a directory into a file, edit it, and then mknod it back to a directory again. What do you mean fsck won't reconnect my file? I'll just make a directory entry and... >>[2] With Internet sockets, how does a machine accept()ing a >> socket connection know what machine is calling it? Does >> it rely on the calling program to tell it? Besides getpeername, there is the concept of privileged ports in UNIX. They can be allocated only by root, and presumably root writes only trusted programs. Like sendmail, ftp, and finger :-) -- Root Boy Jim Cottrell Close the gap of the dark year in between