Date: Sat, 27 Jul 2019 12:13:02 +0200
From: Rocky Hotas <rockyho...@firemail.cc>
Message-ID: <20190727101302.fnmf3k2x47fonjow@delpotro>
| This lets us continue a previous discussion. I struggle to figure out
| why the birth time is useless.
An easy way to counter my argument would be to produce a use for
birthtime - something that you can actually use it for.
Do be aware that "obviously it must be useful" will not do.
If you do that and I cannot show you why it doesn't work (and cannot
easily be fixed to work ... ie: if there happens currently be some bug,
or implementation limitation, that's not relevant) then I'll concede.
If you can't show a use for birthtime which can actually be made to
work, and work properly, all the time (where implemented - that it fails to
work if a file is copied to a filesystem which has no concept of birthtime
is obviously not relevant) - an unreliable field is no use, then I think
you'd have to agree that it is useless.
Note that potential uses for the field which are practically impossible
to implement aren't worthy of consideration. (An absurd example would
be the time when I think of an idea which later gets expressed in some
form in a file ... which might be a useful time to know for proof of patent
non-infringement or something - but there's no practical way that the
time of my thoughts can be extracted and implemented somehow. The
filesystem code needs to be able to implement the use if one can be
discovered.)
| A Last Modified time preceding the birthtime - I think, and correct me
| if I'm wrong - will happen only if the file is moved and its attributes
| are not preserved.
It can't happen as implemented, as whenever the mtime is set earlier
than the birthtime, the birthtime is simply set equal to the mtime.
(This action is independent of whether birthtime is useful or not, if
this behaviour is considered wrong, it can be changed - if the lack of any
other method to explicitly set birthtime is a problem, one could be added,
provided that birthtime has any rational use to make it worthwhile.)
If it weren't for this lowering of birthtime whenever mtime predates
it, then the mtime could be made less then brthtime by anything that
uses the utimes() sys call (or one of its relatives) ... such as:
touch -m -d 'whenever you like' file
A whole bunch of utilities use utimes() for one reason or another.
| If all the file attributes with their timestamps are always preserved
| when it is copied and / or moved, the birthtime is meaningful.
We'll wait to determine that until after you show a use. Note however that
I said useless, not meaningless. Birthtime certainly has a defined meaning,
I simply cannot find any use for a field defined that way. Or any other
way I have ever considered (which could rationally be called birth time).
[Aside: the current definition is that the birthtime is the minimum (ie:
earliest) of all values ever assigned to the mtime field of the inode that
represents the file. Feel free to pick a different definition if you can
find a use for the field however.]
One more thing... there are a vast number of other data items, some of
which might be useful (eg: a file type - as in type of the contents, rather
than the meta-type that currently exists), and others which almost certainly
would not be useful (the size of the drive housing the filesystem upon which
the file was first created) that are also competing for inclusion in inodes.
I could ask you to also justify your proposed birthtime use as being more
useful than all the other (useful) ones ... but I won't even ask for that,
just some practical and implementable use.
| Also, you wrote there is no coherent way to define the birthtime.
That means anything useful, yes. Obviously there are plenty of ways
that one could define any field, and most of those are likely to be coherent.
A definition doesn't make the field useful however, nor would a definition
of some random useful field, which we then arbitrarily call "birthtime"
(even though it is perhaps not a time, or if it is, has nothing to do with
"birth") suffice for this purpose.
| Maybe you refer to the fact that it is not clear, in the case of a moved
| file, if this birthtime should be the time when the file was created
| (regardless of the filesystem it was belonging at that moment), or instead
| the time when the file was created in the filesystem it is currently
| placed. Is this the ambiguity you are referring to?
That there are questions like that is evidence that no-one yet knows
what birthtime is supposed to be useful for. If we knew its use, we'd
be able to work out how it needs to be manipulated. It is because no-one
seems to have any idea what it is to be used for (unlike the three other
inode time fields) that we have questions on how it should be set/updated.
When (if) you supply a use, please be precise - tell me exactly what you're
going to use the field for (and what the requirements are of that use.)
You don't need to expand upon implementation details, of who does what
when, it is the use I am looking for.
And lastly, "so the stat(1) program can print it out, and I can see it"
is not a use, that's an implementation detail - what is needed is what you
would do with the value when it is shown to you, or what some other software
using the value from stat(2) would do with it, somethng that you cannot
(easily perhaps) do without this field.
kre
ps: as I recall it, birthtime was added because some other system had it,
and there was a bout of "we have to be able to do anything they can do"
going on... It wasn't any more useful in the other system, though the
filesystem semantics there were different than those for unix files.
Also, birthtime is not specified by POSIX, so it can't be used portably
in any event - but this is also not an objection if a good use for
the data is found (one which can be implemented in a way that works).
