Hi Andrew,
I found a file in /httpdocs/course
11 -rw-r–r– 1 dev psacln 10534 Jul 24 21:04 edit.phpb4andrewedit20060723
I guess you modified this file on 23 Jul. In that case, the mtime (last modified timestamp) “Jul 24 21:04” is a bit misleading.
Why is this mtime important? The backup filename was designed to be “somefile.phpB4someoneedit….” which tells other programmers (other than yourself) that
“This is the original file BEFORE changes on 20060723”
The mtime of this file should be the day and time when it was last modified BEFORE your edit on 20060723 (therefore mtime cannot be 0724). This information helps track the change history of this file. Obvious Problem with edit.phpb4andrewedit20060723 is this — if u edited it on 20060723, then how can the ORIGINAL have a mtime of next day?
When you are not the only programmer, we need to be careful not to confuse colleagues. Maybe you could try to use “cp -p” as much as possible? When we make a backup of file1, let’s try as much as possible to leave file1 completely intact with all its attributes. Many relatively new Unix users do not realize mtime, ctime, permission, ownership … are all part of the file attributes. This series of commands will NOT keep an intact copy:
cp file1 file1.bak # cp -p is better
vi file1
I was a bit upset when I first noticed edit.phpb4andrewedit20060723 . I will learnt how to be more patient, and I think you can learn to pay more attention to important details. In a way, i write such a long letter in order to calm myself down and let you realize a fine point in collaborative-coding.
Victor (still feeling impatient)