Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!hao!ames!lll-lcc!well!ewhac
From: ewhac@well.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: Cp: A replacement for AmigaDos Copy
Message-ID: <3171@well.UUCP>
Date: Fri, 29-May-87 03:12:59 EDT
Article-I.D.: well.3171
Posted: Fri May 29 03:12:59 1987
Date-Received: Sat, 30-May-87 10:30:00 EDT
References: <741@van-bc.UUCP> <121@gtss.UUCP> <156@l5comp.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Followup-To: net.flame
Distribution: na
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 63
Summary: The End Of It (maybe).

In article <156@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes:
>In article <121@gtss.UUCP> chas@gtss.UUCP (Charles Cleveland) writes:
>>In article <741@van-bc.UUCP> jlydiatt@van-bc.UUCP (Jeff Lydiatt) writes:
>>>
>>>Here is a replacement for AmigaDog "copy" program....
>>>It ... has the added bonus that it retains the date of copied file.
>>
>>This is not a feature, it is a bug :-).  Virtually nobody does it this
>>way and for good reason.  Kindly include this feature as an option only, and
>>not the default one at that.
>One man's bug is another man's feature.
>
>I for one am ALL in favor of having my datestamps left alone when I move files
>around.  [ ... ]

	In the hopes of quelling this argument, I contribute to this flame:

	My orientation is that copy should "modify" the creation date.  The
reason I have the word "modify" in quotes is because you aren't really
modifying the date at all.

	When you invoke "Copy", you make a copy of the file in question.  It
is *NOT* the same file.  The only thing similar between them is their
contents.  By copying the source file, you *create* a totally *new*
destination file.  When creating a new file, it gets the current date.
Thus, you aren't modifying anything.  You are creating a new file (with
today's date), and filling it with the contents of the source file.

	People complain about this behavior because, when copying the files
to floppy from RAM: (or VD0:), it "changes" the dates, and causes problems
with programs like 'make'.

	However, if you think about it for a while, what you're really
doing is *backing up* your data onto floppies.  A backup utility is designed
to preserve the date when backing up and restoring files.  A typical
development cycle might be:  Create file, make, BACKUP to floppy (preserving
dates), test, Guru, reboot (flushing core), RESTORE RAM: drive from floppy
(preserving dates), and trying again.

	By saying "Copy", you're telling the machine that you want to make a
duplicate of a file's contents by *creating* a new file to keep it in.  By
saying "Backup" (or whatever), you're asking the machine to *preserve* your
files in their current state.

	Anyone who might suggest, because the source and destination
filenames are the same, or that the destination file already exists, that
"Copy" should preserve dates is still wrong.  When copying over an existing
file, one of two things happens:  1) A *new* file is created, data copied
and, if successful, the old version deleted,  2) The destination file is
deleted, and a *new* file created and filled with the data.  Asserting that
the source and destination names are the same doesn't prove anything.

	Someone earlier was picking on semantics.  You should call the
backup utility "Backup", or "Preserve", or something along those lines; and
the file copier "Copy".  That is, if you wanted to be picky :-).

	'Nuff said?

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_	 Bike shrunk by popular demand,	      dual ---> !{well,unicom}!ewhac
O----^o	 But it's still the only way to fly.  hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor