Andreas Dilger wrote:
On 20-Oct-09, at 06:44, jim owens wrote:
Restricting the modification of create time is pointless.
You contradict yourself later. What we have NOW is creation timestamps
inside on-disk metadata structures the filesystem does not expose.
Going a step further - to expose this in a read-only manner does not
remove the usefulness of this field, but making it read-write does.
The apparent contradiction is that I forgot to explicitly say
there are two kinds of create time stamps in filesystems:
- "user create time"
- "internal filesystem create time"
My assumption was we were *adding* a "user create time" which
must be settable by things like star that archive and restore.
Otherwise we have "modification time" before "user create time"
when a user restores their files.
An "internal filesystem create time" that is not exposed or
is read-only is different. And AFAIK most linux filesystems
do not have either create time today so unless we want to say
Samba only uses ext4, we need to think broader in scope.
Since no Unix tools or applications depend on the presence of this
field, I would say that the default be to NOT allow this timestamp
to be changed.
If nobody uses the field, what is the need to protect it?
Seems you are now contradicting yourself.
jim
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
