|
Home > Archive > Unix Programming > October 2006 > utime() vs. utimes()
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
utime() vs. utimes()
|
|
| phil-news-nospam@ipal.net 2006-10-24, 7:17 pm |
| Which to use, utime() vs. utimes(), for a program that is copying file
with the intent of making even the meta data identical in the target.
utimes() uses and array of 2 struct timeval, which includes microseconds,
which filesystems may be starting to actually use. But utimes() is marked
"legacy" by SUSv3.
utime() uses struct utimbuf, which has 2 members of type time_t. But this
leaves microseconds set to zero in the target file.
Is SUSv3 moving backwards?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-10-24-1304@ipal.net |
|------------------------------------/-------------------------------------|
| |
| Daniel Rock 2006-10-24, 7:17 pm |
| phil-news-nospam@ipal.net wrote:
> utime() uses struct utimbuf, which has 2 members of type time_t. But this
> leaves microseconds set to zero in the target file.
Since there is no portable way to obtain better-than-seconds granularity
from file time stamps why should you set sub-seconds timestamps?
--
Daniel
| |
| Henry Townsend 2006-10-25, 1:33 am |
| Daniel Rock wrote:
> phil-news-nospam@ipal.net wrote:
I've run into the same problem. It's really quite surprising that the
standards committees didn't even provide a direction forward or a
rationale for deprecating the "better" interface.
[vbcol=seagreen]
> Since there is no portable way to obtain better-than-seconds granularity
> from file time stamps why should you set sub-seconds timestamps?
"No portable way" != "no way". There are plenty of applications which
don't need to be portable, or for which functionality is worth the price
of a few #ifdefs.
HT
| |
| phil-news-nospam@ipal.net 2006-10-25, 1:33 am |
| On Tue, 24 Oct 2006 19:26:13 +0000 (UTC) Daniel Rock <v200643@deadcafe.de> wrote:
| phil-news-nospam@ipal.net wrote:
|> utime() uses struct utimbuf, which has 2 members of type time_t. But this
|> leaves microseconds set to zero in the target file.
|
| Since there is no portable way to obtain better-than-seconds granularity
| from file time stamps why should you set sub-seconds timestamps?
That's silly.
The objective is to get whatever granularity the system and filesystem
have available, and to replicate that value in a file being copied on
that system to a like or compatible filesystem.
What a portable interface could and should is get all of that granularity
in a portable way. Then the very same program when run on a system that
only provides one minute granularity would be copying it as is, unchanged,
and when run on a system that provides nansecond granularity would be copying
that just as is.
Additionally, a system that only has a clock capable of say 100 millisecond
granularity could still be used to literally copy nanosecond granularity
data that was originated from a system that had nanosecond granularity in
its clock.
Where the file metadata simply doesn't have it, these finer values would
just be 0 and that would be copied as 0 and have no effect. But the idea
is to have an interface that can allow for a portable program to be able
to do this on all systems.
And of course we do need to also have a portable way to get that granularity.
So far Unix has been a miserable failure with regard to achieving usable
timing information portability. As long as this failure persists, there
will continue to be non-standard solution created in various systems.
So do you want to join in finding a good way to fix it?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-10-24-2143@ipal.net |
|------------------------------------/-------------------------------------|
| |
| Daniel Rock 2006-10-25, 7:18 am |
| Henry Townsend <henry.townsend@not.here> wrote:
> "No portable way" != "no way". There are plenty of applications which
> don't need to be portable, or for which functionality is worth the price
> of a few #ifdefs.
So why do you want to be portable with setting file times but not while
obtaining them?
--
Daniel
| |
| phil-news-nospam@ipal.net 2006-10-25, 1:27 pm |
| On Tue, 24 Oct 2006 22:43:21 -0400 Henry Townsend <henry.townsend@not.here> wrote:
| "No portable way" != "no way". There are plenty of applications which
| don't need to be portable, or for which functionality is worth the price
| of a few #ifdefs.
Some "portability purists" might argue that a program that copies files
while preserving their timestamps is not truly portable if it does not
behave precisely the same on each platform. In other words, if it does
copy attoseconds of granularity on one, it must also do so on all others.
And since it cannot on all, it isn't a portable program if it does so on
some.
Of course my intent is for the program to "do the best it can on each
platform". I was hoping for "the best" being a portable interface.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-10-25-0930@ipal.net |
|------------------------------------/-------------------------------------|
| |
| phil-news-nospam@ipal.net 2006-10-25, 1:27 pm |
| On Wed, 25 Oct 2006 11:39:30 +0000 (UTC) Daniel Rock <v200643@deadcafe.de> wrote:
| Henry Townsend <henry.townsend@not.here> wrote:
|> "No portable way" != "no way". There are plenty of applications which
|> don't need to be portable, or for which functionality is worth the price
|> of a few #ifdefs.
|
| So why do you want to be portable with setting file times but not while
| obtaining them?
I can't speak for others, but I want to be portable for both. And at the
same time I also want to copy the times as fine as they are recorded.
Why is it that they reduced the granularity of setting the time instead of
increasing the granularity of obtaining it?
Maybe what we need to do is force all systems to use 64 bits for time_t
and require that time_t be the number of _nanoseconds_ since the epoch
instead of mere seconds. That way we kill the granularity problem as
well as the Y2038 problem in one shot. Even with nanoseconds granularity,
a signed 64 bit number won't overflow negative until Friday 11 April 2262
at 23:47:16 plus 854775808 nanoseconds. Given that C implementations that
conform to C99 have a 64 bit type, this can be used for time_t.
And if people do insist on time_t staying at seconds resolution, then just
make a new type, such as "timens_t", and new syscalls for everything that
involves time_t in some way to have a version that uses "timens_t".
FYI, if we use a 10 nanosecond granularity, then the overflow date will be
Tuesday 7 October 4892 at 21:52:48 + 547758080 nanoseconds. So would you
rather have a time type that can serve even your great*100 grandchildren,
or a time type with 10 times the granularity that only lasts until your
great*10 grandchildren?
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-10-25-0934@ipal.net |
|------------------------------------/-------------------------------------|
| |
| Henry Townsend 2006-10-25, 1:27 pm |
| Daniel Rock wrote:
> Henry Townsend <henry.townsend@not.here> wrote:
>
> So why do you want to be portable with setting file times but not while
> obtaining them?
In all my work, I want to be "as portable as possible" while still
preserving the level of required functionality. Each portable construct
reduces the number of ifdefs required to reach the target functionality
and thus makes the code more maintainable. I'm not sure why this is
controversial.
My code is "portable" in the sense that it's been ported to a number of
platforms. I get nanosecond mtime resolution on Solaris, for instance,
by peeking into the stat struct. This is clearly not portable but it's
protected by ifdef.
My particular application relies on sampling file mtimes and sizes. If a
file is modified twice within a second on a platform which supports
finer than 1-second time resolution it could be fooled. So I need to get
the same level of info the filesystem has; ideally this would be doable
with a portable construct but it must be done regardless.
The best example of a program which "must have" the same info as the
filesystem is 'make'. My program is not make but behaves similarly in
this way.
HT
| |
| Daniel Rock 2006-10-25, 1:27 pm |
| Henry Townsend <henry.townsend@not.here> wrote:
> My code is "portable" in the sense that it's been ported to a number of
> platforms. I get nanosecond mtime resolution on Solaris, for instance,
> by peeking into the stat struct. This is clearly not portable but it's
> protected by ifdef.
No, with UFS you will only get usec resolution.
> The best example of a program which "must have" the same info as the
> filesystem is 'make'. My program is not make but behaves similarly in
> this way.
Make is quite happy with only seconds resolution. For any granularity there
will be a time interval which will compare as equal. The standard defined
a second should be sufficient. If you cannot live with that, then
program unportable.
--
Daniel
| |
| Eric Sosman 2006-10-25, 1:27 pm |
|
phil-news-nospam@ipal.net wrote On 10/25/06 11:03,:
> [...]
> Maybe what we need to do is force all systems to use 64 bits for time_t
> and require that time_t be the number of _nanoseconds_ since the epoch
> instead of mere seconds. [...]
Ever heard the tale of King Canute commanding the waves?
--
Eric.Sosman@sun.com
| |
| Henry Townsend 2006-10-25, 1:27 pm |
| Daniel Rock wrote:
> Henry Townsend <henry.townsend@not.here> wrote:
>
> No, with UFS you will only get usec resolution.
You're being deliberately argumentative - did you get up on the wrong
side of bed today? The Solaris stat structure stores nanosecond
resolution; it doesn't matter what the underlying FS can do as long as
it's not finer-grained than nanosecond. This just means all the
timestamps read out of the stat structure for UFS files will end with
three zeroes.
In other words _Solaris_ can handle nanoseconds - it's _UFS_ that
provides the usec limitation. I did say that the point was to get the
best data available, which is unaffected by the UFS sidetrack.
>
> Make is quite happy with only seconds resolution. For any granularity there
> will be a time interval which will compare as equal. The standard defined
> a second should be sufficient.
Make may be happy but it can happily do the wrong thing, thus making the
developer unhappy. This stuff is old and has been hashed out before.
Don't believe me? Check out GNU make's .LOW_RESOLUTION_TIME feature and
rationale.
> If you cannot live with that, then program unportable.
Oh, I'm sorry, I must have stumbled into comp.lang.portable-only by
mistake! I meant to be in comp.unix.programmer where portability issues
are discussed as a fact of life.
HT
| |
| phil-news-nospam@ipal.net 2006-10-25, 7:15 pm |
| On Wed, 25 Oct 2006 16:52:09 +0000 (UTC) Daniel Rock <v200643@deadcafe.de> wrote:
| Henry Townsend <henry.townsend@not.here> wrote:
|> My code is "portable" in the sense that it's been ported to a number of
|> platforms. I get nanosecond mtime resolution on Solaris, for instance,
|> by peeking into the stat struct. This is clearly not portable but it's
|> protected by ifdef.
|
| No, with UFS you will only get usec resolution.
Whether microsecond or nanosecond or attosecond ... standard Unix is
behind the times on this. They should have standardized _how_ to do
this _before_ we needed to do it. Now there are bunch of non-portable
ways, and some of those may even break when a portable method finally
comes around.
|> The best example of a program which "must have" the same info as the
|> filesystem is 'make'. My program is not make but behaves similarly in
|> this way.
|
| Make is quite happy with only seconds resolution. For any granularity there
| will be a time interval which will compare as equal. The standard defined
| a second should be sufficient. If you cannot live with that, then
| program unportable.
The speed of things taking place these days means it is possible for some
changes to files to take place within a second. A granularity of one
microsecond should be good enough for a few more years. Eventually we
will need even more. I have encountered this kind of problem myself
and it was on a not all that fast machine (800 MHz). But it was elusive
and I actually saw it happen several times before I finally figured out
what was happeing. Adding a sleep of 1 second to some script cured it
(so far).
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-10-25-1726@ipal.net |
|------------------------------------/-------------------------------------|
| |
| Gordon Burditt 2006-10-25, 7:15 pm |
| >Maybe what we need to do is force all systems to use 64 bits for time_t
>and require that time_t be the number of _nanoseconds_ since the epoch
>instead of mere seconds. That way we kill the granularity problem as
>well as the Y2038 problem in one shot.
I prefer making it the number of yoctoseconds since the beginning of the
universe. Problems, though:
(1) It's not POSIX.
(2) It requires 128 bits.
But it does solve the Y2038 problem and the granularity problem.
| |
| Geoff Clare 2006-10-26, 1:15 pm |
| phil-news-nospam@ipal.net wrote, on Tue, 24 Oct 2006:
> Which to use, utime() vs. utimes(), for a program that is copying file
> with the intent of making even the meta data identical in the target.
>
> utimes() uses and array of 2 struct timeval, which includes microseconds,
> which filesystems may be starting to actually use. But utimes() is marked
> "legacy" by SUSv3.
>
> utime() uses struct utimbuf, which has 2 members of type time_t. But this
> leaves microseconds set to zero in the target file.
>
> Is SUSv3 moving backwards?
Yes, SUSv3 went the wrong way here. It is going to be corrected
in SUSv4, where utimes() will be mandated and utime() will be
marked obsolescent. (Of course, that isn't set in stone until
SUSv4 is published, but it is the current consensus.)
There is also a plan to introduce a way to get nanosecond
timestamps from stat(), but (from memory) there are two different
proposals and it remains to be seen which one will be adopted.
I think one of them is what Solaris does.
--
Geoff Clare <netnews@gclare.org.uk>
| |
| phil-news-nospam@ipal.net 2006-10-26, 7:19 pm |
| On Wed, 25 Oct 2006 23:40:21 -0000 Gordon Burditt <gordonb.gsemn@burditt.org> wrote:
|>Maybe what we need to do is force all systems to use 64 bits for time_t
|>and require that time_t be the number of _nanoseconds_ since the epoch
|>instead of mere seconds. That way we kill the granularity problem as
|>well as the Y2038 problem in one shot.
|
| I prefer making it the number of yoctoseconds since the beginning of the
| universe. Problems, though:
|
| (1) It's not POSIX.
| (2) It requires 128 bits.
|
| But it does solve the Y2038 problem and the granularity problem.
Make it be Posix.
It will be practical in just a few years.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-10-26-1442@ipal.net |
|------------------------------------/-------------------------------------|
| |
| phil-news-nospam@ipal.net 2006-10-26, 7:19 pm |
| On Thu, 26 Oct 2006 13:59:57 +0100 Geoff Clare <geoff@clare.see-my-signature.invalid> wrote:
| phil-news-nospam@ipal.net wrote, on Tue, 24 Oct 2006:
|
|> Which to use, utime() vs. utimes(), for a program that is copying file
|> with the intent of making even the meta data identical in the target.
|>
|> utimes() uses and array of 2 struct timeval, which includes microseconds,
|> which filesystems may be starting to actually use. But utimes() is marked
|> "legacy" by SUSv3.
|>
|> utime() uses struct utimbuf, which has 2 members of type time_t. But this
|> leaves microseconds set to zero in the target file.
|>
|> Is SUSv3 moving backwards?
|
| Yes, SUSv3 went the wrong way here. It is going to be corrected
| in SUSv4, where utimes() will be mandated and utime() will be
| marked obsolescent. (Of course, that isn't set in stone until
| SUSv4 is published, but it is the current consensus.)
|
| There is also a plan to introduce a way to get nanosecond
| timestamps from stat(), but (from memory) there are two different
| proposals and it remains to be seen which one will be adopted.
| I think one of them is what Solaris does.
Too bad they make choices based one what someone already does, rather
than make choices based on what works best overall and makes sense.
What machine that conforms to the latest standard C cannot handle
a 64 bit integer either in hardware or by compiled simulation?
There is no reason to not mandate a 64 bit integer for this.
Everything gets simpler when it is just a straight number, whatever
the granularity and epoch.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-10-26-1443@ipal.net |
|------------------------------------/-------------------------------------|
|
|
|
|
|