john@viper.UUCP (John Stanley) (04/22/87)
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
ram-ashwin@YALE.ARPA.UUCP (05/05/87)
Issue: Time-stamping a copied file with the date/time of the copy operation
vs. time-stamping it with the date/time of the original file.
I can think of cases for each possibility in which it would be the better
thing to do. One solution (implemented by the Aegis operating system on
Apollo workstations, for example) is to time-stamp each file with TWO times
-- the time that the file was CREATED, and the time it was LAST MODIFIED
(Apollo also has the time it was LAST USED, which isn't relevant here). When
you copy a file, you can choose to preserve the date/time information on the
copy, in which case the CREATED time of the copy is the current time, but the
LAST MODIFIED time is the last modified time of the original file (probably
the time of the last USEFUL change). A user (or a program) can now make use
of whichever piece of information is relevant.
Voila -- both parties happy.
-- Ashwin Ram --
ARPA: Ram-Ashwin@yale
UUCP: {decvax,linus,seismo}!yale!Ram-Ashwin
BITNET: Ram@yalecs