Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!topaz.rutgers.edu!ron
From: ron@topaz.rutgers.edu (Ron Natalie)
Newsgroups: comp.unix.wizards
Subject: Re: Open question on NFS, efficiency, etc.
Message-ID: <13849@topaz.rutgers.edu>
Date: Mon, 10-Aug-87 16:59:41 EDT
Article-I.D.: topaz.13849
Posted: Mon Aug 10 16:59:41 1987
Date-Received: Tue, 11-Aug-87 05:37:01 EDT
References: <8730@brl-adm.ARPA>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 21

One of the big advantages of NFS (or RFS for that matter) over past
remote file system hacks is that it is (program wise) totally transparent
to use the remote filesystems.  You do not have to recompile or "know"
specifically about whether you are doing a local or remote access.  I'd
avoid this.  By the way, the fix that really needs to be done to the
cp and rcp programs in this day of multiple access is to fix the silly
code that tries to keep you from screwing yourself when you say
"cp A B" when A and B are the same file.  People feebly try to stat the
inode and check internet addresses and all kinds of things to determine
if the file is the same.  There is no foolproof way to do this.

I suggested that if the cp A B was not destructive when A and B are the
same file, then you could do away with this check and the user gets
precisely what he asked for without destroying anything.  When I mentioned
this to Doug Kingston, he figured out that if you do not "creat" over an
existing file, but just read one and write the other and the "truncate"
to the correct lenghth after you are done, you do not screw things.
Unfortunately we thought of this too late to be on the 4.3 tapes (it is
available on the BRL releases though).

-Ron