dickey@cwruecmp.UUCP (Lee Dickey) (04/23/87)
In article <478@orville.UUCP> bob@wiley.UUCP (Bob Amstadt) writes: >In article <859@viper.UUCP> john@viper.UUCP (John Stanley) writes: > >> One important thing I'd like to see -all- shell writers do is to get >> the old date and time properly transfered to the new file. It's not >> very complicated (takes about 5 lines of C) and makes the copy function >> -much- more useful... (Ever try using MAKE in a system where copying >> your files flakes out the date and time info? It doesn't work...! :( > >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). John Stanley has the right idea here, for two reasons. (1) Modifying the date means that information is lost, information that can not be reinstated by the user. (2) Amstadt has another (easy) solution to *his* problem. In doing a restore from a backup copy with the intention of doing a MAKE, he is doing something quite specialized, and even for himself, might find it useful to know when a file was created in some other context. The solution to his problem is to simply "touch" the file. I vote for keeping the preserving the create or modify date when a file is copied.
hans@umd5.UUCP (04/28/87)
[] This discussion has turned into an insult to all programmers. The basic premise seems to be that copy programs can either change the date of files, or not change it. (Either approach has its uses). Surely some of the capable ST programmers around can conceive of software that optionally will do one or the other!