jwg@galbp.UUCP (Joe Guthridge) (02/05/85)
My apologies to those who replied to me a month ago with some of this info. I now have a working list of systems which I list below. We are in the process of gathering details on each and I will give a short descripion of each when that's all finished. The UN*X transparent remote file access systems I am researching are: 1. IBIS 2. Worknet 3. Sun's NFS 4. Newcastle Connection 5. Locus' LCC (from UCLA) 6. COCANET 7. Masscomp's system 8. Casdmus' UNISON 9. Plexus' NOS 10. TEK's DFS 11. ISC's system 12. RIDE 13. HP's RFA If you know of any others, please mail to me. Thanks to those who've responded so far. -- Joe Guthridge ..!akgua!galbp!jwg
monte@oblio.UUCP (Monte Pickard) (02/09/85)
Thanx for posting the results to your search for 'Transparent Remote File Access Systems'. I am somewhat surprised at all the entries in your search. When we first demo'd the Plexus NOS entry at UNICOM in San Diego in 1983, there were no others that provided remote transparent access. Just two years later, I am somewhat sceptical that all those on your list provide 'transparent' access to remote file systems. I would like to offer the following minimum definition for qualifying as a 'transparent' remote file access system: * all files are accessed with 'path-names' that have the same syntax for local files and remote files. (this does not mean location-independence, just same syntax) * all applications running, that allow access to the file system through path-name parameters (i.e normal Unix applications (cmd's) like cp, ls, cc, etc.) must be able to run, without modification, on files that are local or remote, with inter-system operablility. (syntax is not good enough, functionality for file and directories, at least, must be provided in the Unix case. A path element must be a valid 'local' Unix object, transparently) This is only a minimum, I would like to see more stringent OS interface standards for local/remote file access (especially in Unix), but this seems to me to be a minimum for the 'transparent' case. I am not knocking the non-transparent case. Getting the job done, is getting the job done, anyway! Functionality, regardless of how cumbersome, is better than not being able to do it (as many systems can not). Also, this should be true for all 'transparent' file system interfaces, be it Unix to Unix, Unix to PC/MS-DOS, MS-DOS to MS-DOS, or X-OS to Y-OS. The Worknet, Sun, LOCUS, Newcastle, and Plexus sytems do this from my standpoint. It is arguable which does the best job at transparency. I do not know if the others you listed do. I am looking forward to your/others summaries of each systems functionality from the transparent aspects of local vs. remote file system access. When a standard does emerge, it is our duty to have influenced it for the overall good of the networking industry in general, not just for the benifit of few (i.e each individual start-up or big company). To me, inter-operability of the various emerging operating system 'standards', is essencial in the development of the computer industry as a whole. Monte Pickard Counterpoint Computers ..!ucbvax!hplabs!oblio!monte
david@daisy.UUCP (David Schachter) (02/21/85)
Daisy Systems was not listed in the summary. Our network support is based
on Ethernet, conforming to XNS (pretty strictly, our troika of LAN gurus
tells me.) To refer to a local file, you use a standard Unix-style path-
name:
"ls /usr/david"
To refer to a remote file on some other Ethernet node, you still use a
standard Unix-style pathname prefixed with the node name:
"ls /net/david/usr/david"
The "/net" tells the name server where to go, it pulls the ".../david..."
out as a node name and sends the ".../usr/david" off to the remote node
named "david". The "/net" is not fixed, it is merely the default: local
installations can change it to valid Unix-style filename. Ditto for node
names, I think.
Can't get usefully more transparent....jlw@ariel.UUCP (J.WOOD) (03/02/85)
I don't think that this represents a very transparent filesharing system at all. In the scenario: /usr/david on host: david is addressed as: /net/david/usr/david The user has to know not only that the fiel is remote but also what host it is on. What if this were netnews on a remote system that you were reading to save block on the local system. What happens when the administrator needs to move news? Do all the interface programs have to be recompiled? Joseph L. Wood, III AT&T Information Systems Laboratories, Holmdel (201) 834-3759 <ariel!>titania!jlw
wls@astrovax.UUCP (William L. Sebok) (03/08/85)
> I don't think that this represents a very transparent filesharing > system at all. In the scenario: > /usr/david > on host: david is addressed as: > /net/david/usr/david > The user has to know not only that the fiel is remote but also > what host it is on. What if this were netnews on a remote > system that you were reading to save block on the local system. > What happens when the administrator needs to move news? Do > all the interface programs have to be recompiled? > Joseph L. Wood, III Thats where 4.2 BSD-style symbolic links are beautiful. Just make the local /usr/spool/news a symbolic link to /net/david/usr/spool/news -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls