Hi Michael,
Thank you for your valuable inputs.
On 2011/04/08 18:48, Michael Stahl wrote:
On 07/04/2011 05:03, tora - Takamichi Akiyama wrote:
I have just come up with a quick solution for the file systems using nanosecond
time stamps.
Problem:
make: *** Warning: .LOW_RESOLUTION_TIME file
`/xxxxx/solver/300/unxsoli4/inc/svx/sxsoitm.hxx' has a high resolution time
stamp
Cause:
"cp -p" does not preserve a nanosecond part of time stamp.
i've just checked on Solaris 11 express:
both /usr/gnu/bin/cp [cp (GNU coreutils) 8.5] and /usr/bin/touch -r seem
to support nano-second timestamps.
That is a good news!
This is my first impression when I have glanced at a source code of both OpenSolaris and
GNU versions of "cp" command.
They simply call fts_open() and fts_read() to obtain a nanosecond time stamp of
original file and then set it to a newly created file.
There seems no specific source code line about rounding-up or ignoring a
nanosecond part.
Therefore, I have concluded -- but not confirmed yet -- the OS that I am
currently using might not be capable of setting nanosecond resolution to a file
through the existing system call level API.
$ cat /etc/release
Solaris Express Community Edition snv_107 X86
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 26 January 2009
Michael's check result implies that the recent Solaris 11 express, obviously
newer than what I am using, has become capable of both obtaining and assign a
time stamp in nanosecond resolution.
That's very nice. I appreciate you for checking it.
Possible Solution:
"touch itself" before "cp -p" to loose a nanosecond part of its time stamp.
hmmm... this could work around the problem, but kind of interferes with
our goal of a read-only source directory :)
Yep, definitely! :)
e.g. In my work environment,
Zone A) hg pull, hg qnew, editing some source files, ...
Zone B) building ooo.
Zone C) testing it with a debugger. the directory is loop-back mounted with a
read-only option.
Okay, I am stopping digging this issue. It would shortly become unnecessary
with Solaris 11.
perhaps just installing new GNU coreutils on systems where this problem
occurs is the way to go...
That's right!
Just in my case, the chance would be coming when my ZFS RAIDZ2 configured six
1.5TB disks reaches at disk full and consequently I would be forced to
reconstruct my system with the latest OS.
Thanks again, ciao,
Tora
--
-----------------------------------------------------------------
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help
