ct@dde.uucp (Claus Tondering) (05/18/89)
System V Release 4.0 will support both symbolic links and RFS. Question: If a remote file is a symbolic link, will that symbolic link be interpreted on the remote machine or on the client? Consider the following scenario: Remote machine: File /alpha/foo is a symbolic link containing "/beta/foo". File /beta/foo contains text "Hello". Directory /alpha has been advertised as resource ALPHA. My machine: Resource ALPHA has been mounted as /gamma. File /beta/foo contains text "Good bye". I now read from file /gamma/foo. Will I read "Hello" or "Good bye"? Either answer seems to break the transparentness of RFS: If the symbolic link is interpreted on the remote machine, I cannot create a remote file as a symbolic link to one of my local files. This is not transparent. If the symbolic link is interpreted on the local machine, the contents of a remote file (in this case the file "foo" under resource ALPHA) depends on the eyes that see it. This is not transparent. And it is also rather useless. -- Claus Tondering Dansk Data Elektronik A/S, Herlev, Denmark E-mail: ct@dde.dk or ...!uunet!mcvax!dkuug!dde!ct
cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) (05/19/89)
In article <563@Aragorn.dde.uucp>, ct@dde.uucp (Claus Tondering) writes: | System V Release 4.0 will support both symbolic links and RFS. | | Question: If a remote file is a symbolic link, will that symbolic link | be interpreted on the remote machine or on the client? | | <example deleted> > Either answer seems to break the transparentness of RFS: | | If the symbolic link is interpreted on the remote machine, I cannot | create a remote file as a symbolic link to one of my local files. This | is not transparent. | | If the symbolic link is interpreted on the local machine, the contents | of a remote file (in this case the file "foo" under resource ALPHA) depends | on the eyes that see it. This is not transparent. And it is also rather | useless. Disclaimer: I have no idea whow the people in Summit actually plan to do this, these are just my opinions... I assume that things will follow the way they already work in NFS, which is that the symlink is interpreted on the local machine. Essentially, the way symlinks work is that when you do an open() of a symlink, the name of the file you're trying to open is remapped to the name the link points to before the actual open is performed (obviously this is simplified). Using this scenario, the mapping would have to take place with regards to the local machine. Acutally this gives some very nice results if you know how to use it. For instance, around here we mount /usr on our Suns from a common server, but /usr/spool is a symlink back to a location on the workstation's private disk. The same goes for /usr/tmp and a few others. If the link was interpreted remotely, we'd have to mount all the directories we wanted under /usr instead of /usr itself in order to allow the local workstations their own space for UUCP, mail, etc. If you want the symlinks to be interpreted closer to the way they would be on the remote machine, use relative paths. For instance, ALPHA may not be mounted as /alpha on the remote machine, but as /foo/alpha, but if a symlink /alpha/beta/foo points to ../bar it will point to the file /alpha/bar on the server machine, and to /foo/alpha/bar on the client machine, but they'll still be the same file. Also, if the names were mapped remotely, it leaves the possibility that the symlink points to a file is not on a remotely mounted file system, or to a file system which is not allowed to be remotely mounted by the client trying to access it. -- Name: Christopher J. Calabrese Brain loaned to: AT&T Bell Laboratories, Murray Hill, NJ att!ulysses!cjc cjc@ulysses.att.com Obligatory Quote: ``Anyone who would tell you that would also try and sell you the Brooklyn Bridge.''
guy@auspex.auspex.com (Guy Harris) (05/20/89)
>Question: If a remote file is a symbolic link, will that symbolic link >be interpreted on the remote machine or on the client? I think it'll be interpreted on the client. >Either answer seems to break the transparentness of RFS: Yup. As the saying goes, Shit Happens. >If the symbolic link is interpreted on the local machine, the contents >of a remote file (in this case the file "foo" under resource ALPHA) depends >on the eyes that see it. This is not transparent. And it is also rather >useless. Wrongo. It is *not* useless. There are times when I've *wanted* to have a symbolic link on a server point to different files on different clients of that server. Consider, for example, the SunOS 4.0 scheme for supporting diskless clients. You have a directory name "/var" in which things like mail spool areas, printer spool areas, accounting files, etc. are put; however, many of those areas have "old-fashioned" names containing "/usr" rather than "/var" - e.g., "/usr/adm". "/usr" is a file system that is exported read-only to the diskless clients, and is shared by the clients; you can't put "/usr/adm", "/usr/spool", etc. there. So "/usr/spool" is a symbolic link to "/var/spool", which is a directory on your local machine. The problem is ultimately intrinsic to any distributed file system where you're allowed to mount directories from remote machines on arbitrary mount points; you don't have a common global file system name space that's *identical* on all machines, and there are, frankly, reasons why you may not want to have that (for instance, when at Sun, I mounted the "/usr/src/man" directory from the main development source repository machine atop "/usr/man", so that any time anybody checked in a new man page I'd get it as part of my on-line man pages; other users wouldn't necessarily want this, since they might be running a stable version of the OS and would want a stable version of the man pages).
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/21/89)
You don't have to be using a network file system to have symbolic links point at different files depending on context. Even on traditional UNIX, changing the mount configuration can affect the target of a symbolic link. As I've said before, I think symbolic links were an unsuccessful experiment; a better solution is needed.
bzs@bu-cs.BU.EDU (Barry Shein) (05/21/89)
From: gwyn@smoke.BRL.MIL (Doug Gwyn) >You don't have to be using a network file system to have symbolic >links point at different files depending on context. Even on >traditional UNIX, changing the mount configuration can affect the >target of a symbolic link. As I've said before, I think symbolic >links were an unsuccessful experiment; a better solution is needed. I think that's harsh but the question deserves discussion. Symlinks generalized hard links by delaying the evaluation of the file path until access time (although the effect seems more dramatic this is basically what the difference is.) The next obvious extension would be to delay the creation of the file path string until access time. The easiest way to do this would be to have a file type which is actually a program which promises to produce a string for namei. Accessing the inode fires up the program and waits for the resultant string which specifies the rest of the path to use. Just as a pre-emptive comment I think immediately going after all the ways this might be abused is not yet interesting since safeguards could be added and obviously the design is not yet fleshed out enough to take seriously someone pointing up bugs. Its utility and possible implementation details would be interesting (it might not make it past that scrutiny so why bother nitpicking possible bugs is my point.) -- -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
ekrell@hector.UUCP (Eduardo Krell) (05/22/89)
In article <31533@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >Symlinks generalized hard links by delaying the evaluation of the file >path until access time (although the effect seems more dramatic this >is basically what the difference is.) Well, it looks to me that the big difference is that symbolic links allow you to go outside your file system. You just can't do that with hard links. In an NFS/RFS environment, either way of interpreting symbolic links (by the client or the server) will break something. We need something more powerful. Apollo extended the symbolic links to include an environment variable in the link text. Then you can have symbolic links which look like "/$(HOST)/foo/bar" which will expand to whatever you $HOST variable is set. Locus had a way of making a symbolic link to point to the local root (ie, relative to the server) by having a special name like "/<LOCAL>" being interpreted by the kernel to refer to the local root and not the client's root. There wasn't an actual "<LOCAL>" entry in /, it's just a special name which the kernel knows about. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
benson@odi.com (Benson Margulies) (05/22/89)
In article <31533@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > > >The easiest way to do this would be to have a file type which is >actually a program which promises to produce a string for namei. Seems to me that this newsgroup is re-inventing Multics (again). One of the things that made Multics more flexible than Unix was that the resolution of strings into I/O resources was done in user code (usually in shared libraries). That is, to get the equivalent of a file descriptor, one does/did (approximately): call iox_$open ("log_output", "log_io_ >udd>Foo>Margulies>log", iocbp, code); or call iox_$open ("log_output", "discard_", iocbp, code); In the first example, log_output_ is a program that interposes itself between the standard I/O interfaces (equivalent of the unix f* interfaces) and a log file, providing log formatting. The second example demonstrates that there was no need for a kernel /dev/null driver. The only code in the kernel was the actual code that spoke to the hardware, and it usually wasn't device specific. For example, all tape smarts were user code. The kernel support was a generic interface for assigning a device and enforcing access control. Now that shared libraries (albeit depressingly cumbersome ones) are spreading through Unix, there is no reason that Unix couldn't grow this sort of feature. As a refinement of barry's comment, consider a file type like a symbolic link. The contents of this file would be instructions, like the descriptions above, of how to dynamically link to a program to actually do the I/O. Benson I. Margulies
rbj@dsys.icst.nbs.gov (Root Boy Jim) (05/24/89)
? From: Barry Shein <bzs@bu-cs.bu.edu> ? The easiest way to do this would be to have a file type which is ? actually a program which promises to produce a string for namei. ? Accessing the inode fires up the program and waits for the resultant ? string which specifies the rest of the path to use. Interesting, but this just repackages the problem. On which machine do you execute the program. It would seem to have to be the target machine, or else you'd need multiple versions of that program. Another solution would be to allow the pathname to contain a host as part of its name: foo -> bar:/path/name. Ultimately, I think the thing to do is to force a specific syntax for a uniform file system, rather than allowing generalized mounts. So rather than allowing a mounting of server:/usr/man on /usr/man, /usr/man would have to be a symbolic link to server:/usr/man. I love symbolic links and will defend them to my death, but I'm beginning to believe in Doug Gwyn's reservations about them. ? -Barry Shein, Software Tool & Die ? There's nothing more terrifying to hardware vendors than ? satisfied customers. So Barry, what happened with Encore? Root Boy Jim is what I am Are you what you are or what?
bzs@bu-cs.bu.edu (Barry Shein) (05/24/89)
>? Accessing the inode fires up the program and waits for the resultant >? string which specifies the rest of the path to use. > >Interesting, but this just repackages the problem. On which machine >do you execute the program. It would seem to have to be the target >machine, or else you'd need multiple versions of that program. Nah, I'm cagier than that, the program could decide to do an rsh (or moral equivalent.) It was no accident that my suggestion was Turing complete (in a manner of speaking.) How would the program *know* which machine it should execute on? Well, heck, whatever other solution you might suggest is open to this one, at that point it's the typical namespace games, somewhere there must be some info or else there is no solution possible (eg. namei passes the program the entire path via argv and the program decides if that's interesting.) >Another solution would be to allow the pathname to contain a host >as part of its name: foo -> bar:/path/name. But I think there was more to this whole symlink thing than just reaching over to another machine. The point is that this sort of thing (choosing a host) is just one of zillions of things you could do once you've decided to fire up a program to complete the path name (eg. look in the person's environment, look at the rest of the path, look in a data base which tells it where this guy's mumfle files are stored, decide it's after 5PM so this is an unauthorized access anyhow so kick him/her/it out and send mail to someone about the attempt etc etc.) My guess is that thinking in broader terms like this is more what's troubling folks about symlinks, it's a significant facility that only solves a few problems. The nagging feeling remains that a much broader solution which encompasses symlinks as one possible use is possible. The watchdog paper comes pretty close (I think it was the last SF USENIX, last few USENIXI anyhow) but puts the process somewhere else (which has its merits as a solution.) I was also under the impression that some of the original Streams thinking (and file switch stuff) was attacking a similar problem.) >So Barry, what happened with Encore? They're alive and well and still house many friends, I've done a context switch. -Barry Shein Software Tool & Die, Purveyors to the Trade 1330 Beacon Street, Brookline, MA 02146, (617) 739-0202
brent%terra@Sun.COM (Brent Callaghan) (05/26/89)
In article <11555@ulysses.homer.nj.att.com>, cjc@ulysses.homer.nj.att.com (Chris Calabrese[mav]) writes: > I assume that things will follow the way they already work > in NFS, which is that the symlink is interpreted on the local machine. > : > Actually this gives some very nice results if you know how to use it. > For instance, around here we mount /usr on our Suns from a common > server, but /usr/spool is a symlink back to a location on the > workstation's private disk. The same goes for /usr/tmp and a few > others. If the link was interpreted remotely, we'd have to mount all > the directories we wanted under /usr instead of /usr itself in order > to allow the local workstations their own space for UUCP, mail, etc. This gets even nicer if you work at a site where the most machines have the automounter mounted on /net. Servers can export filesystems containing symbolic links that have /net in the path. If the client touches one of these then the client's automounter mounts the required filesystem and resolves the path. The big advantage of symbolic links over hard links used to be that you didn't have to worry about cross-partition references anymore. With /net paths you don't have to worry about cross-server references either! Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051
brent%terra@Sun.COM (Brent Callaghan) (05/26/89)
In article <31533@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: > > The next obvious extension would be to delay the creation of the file > path string until access time. > > The easiest way to do this would be to have a file type which is > actually a program which promises to produce a string for namei. > > Accessing the inode fires up the program and waits for the resultant > string which specifies the rest of the path to use. > -- > -Barry Shein, Software Tool & Die Well this almost how the automounter in SunOs works. It mounts itself in the filesystem on the host and pretends to be a directory NFS mounted from another server. It responds to the NFS RPC calls from the kernel and sends back appropriate responses. This interposition allows the automounter to catch references to filesystems and mount them on the fly. The latest version of the automounter can also emulate a symbolic link at its mount point. It can point the symlink wherever it pleases when the kernel does an NFS READLINK request. Things can get a bit slippery when it comes time to unmount this thing - but that's a whole 'nuther story.... Although I know of no examples, there's no reason why such an NFS daemon couldn`t emulate a regular file at its mount point and behave accordingly when the kernel issues READ and/or WRITE requests. Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 336 1051