🚀 go-pugleaf

  Sorry this msg is a bit "flaming", but I've had too many times go
by where if this had been done right it would have saved me (and at 
least 15 other people I know of) a -lot- of time and effort.  Bob
is entitled to his opinion, but I really see no rational reason to
encourage shell writers to write copy functions which throw away
valuable information...

--------

In article <478@orville.UUCP> bob@wiley.UUCP (Bob Amstadt) writes:
 >
 >I disagree. It is very important copy updates the date to the current date
 >and time. Example: I make some changes to a file which later proves to be
 >damaging or useless. I get back the original source from a backup. This
 >constitutes a change and therefore should affect the last modified date.
 >If you are using MAKE, then you shouldn't move your files (at least not
 >very often).
 >

  Well Bob, you're intitled to disagree, but I strongly disagree with
your example.  When you copied over your most recient copy with your
backup, yes, you have made a change and the file date should be effected,
but the effect should be one which will tell you the resulting file is
identical to the backup.  The -contents- of the newly copied file is
the source from 25 days ago, not something changed when it got
copied over the more recient version...
 
  There are plenty of examples of systems where the change date is
copied along with the contents of a file.  This provides a very useful
and desireable function.  On the other hand, stamping the file with
the copy date only destroys information that would be useful and gives
nothing useful in return.  (Anyone who thinks the most useful thing for
a shell to do when you move a folder to someplace new on your hard disk
is to stamp all the source/text files with the exact same time and date
(destroying any hope of telling when something was actualy changed),
please report to your nearest mental clinic.. (only 1/2 :-) )

  If the desktop worked the way I'm suggesting, it would be painless
to make backups by draging files to a backup floppy.  You could easily
tell when the true last-change was made to any backup file with ease.
As it stands with the desktop and with many of the simple shells, the
only thing you know when you have a copy is when you copied it, not
something useful like when it got changed or if it's identical to some
other file that's been copied 3 times since then.

  It would also make it -much- less painful to rearange a hard disk.  
As things stand, if someone wants to change how things are laid out, 
they -loose- all rational information related to date-time stamping...
You consider this rational?  (feh!)

[flameon]

  As for whether I "should" or "shouldn't" be moving files, what right
do you have to tell me what my needs "should" be?!?  I have perfectly
good and reasonable reasons for wanting to keep multiple backup copys
and have to make copys for transfer to other people working on the 
development projects I work on.  Why shouldn't I have the right to 
easily copy files and have a useable/rational result?

[flameoff]

  If the only reason you say that I "shouldn't" move files effected
by MAKE is because some shell writers don't copy the date+time, then 
don't you think it would be a "real-good-idea" if some of them thought
about doing it?  (And "maybe" it would be another real-good-idea if I
remind a few of them (including Atari) that it's needed...??)

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john