[NTLUG:Discuss] original file creation date?

[Eric Schnoebelen]

Kenneth Loafman writes:
- Eric Schnoebelen wrote:
- > - The camera download programs must be setting the creation
- > - time, otherwise it would be identical to the modification
- > - time.  It would be trivial for them to set the modification
- > - time as well, but that would not match the normal semantics.
- > 
- > No, the creation time can be newer than the modification time.
- > inode creation time can  never be updated.  inode/file access and
- > modification times can be updated by the utime(2) system call.
- 
- If its not possible to update the ctime, then how is it possible
- for the camera download programs to recreate the file with ctime
- equal to the time that the picture was taken?  I have both the
- info from the camera and the ls -lc of the download that agree
- to the second on the ctime, and mtime matches the time the download
- was done.  This implies that there has to be a mechanism to update
- ctime.

Which programs?  I'd like to take a look at their source, and
see what they are doing.

However, having worked for various UNIX OS vendors over the
years, and having maintained/enhanced core backup/recovery
utilities such as dump(8) and restore(8), I've not seen any
utility that can modify the inode creation time.

- On another note, I think the semantics of cp have changed in the
- last few years, and not to the better.  It used to be that cp as
- root would automatically imply --preserve.  Now it does not.
- Not a good change.

``--preserve'' is a GNU-ism, and didn't exist in the historic
edition of cp(1). (even -r/-p didn't exist until cp(1) was over 15
years old.)

I would suspect the developers of the GNU version changed the
semantics to better follow the POSIX.2 standards at some point.
(gack, the number of options cp(1) has grown as part of GNU's
coreutils!)

--
Eric Schnoebelen		eric at cirr.com		http://www.cirr.com
	License plate seen on a car speeding by me: 4VRLATE