-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
With the introduction of the nanosecond fields in struct stat the
utime() syscall is kind of obsolete. It's not possible anymore to
restore the exact access/modification time of a file.
Unix defines the utimes() function for this. It is currently
implementated in glibc on top of the utime() syscall which used to be OK
but isn't anymore today. In addition some systems provide the futimes()
and lutimes() functions which appropriate semantics.
The question: would a patch introducing these syscalls be accepted? If
there are filesystems which store the sub-seconds on disk I think this
is necessary since otherwise all kinds of programs (including archives)
cannot be written correctly. If the sub-seconds only live in memory I
still think it would be good to have the syscalls but it would not be
that urgent.
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/D5sS2ijCOnn/RHQRAjhgAJoCHPLGWjvK6VUxVmyJx/MPnwzjeQCggpmy
1qKasu1RgrliP4QA0t9QuUE=
=NQyO
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ulrich Drepper wrote:
> With the introduction of the nanosecond fields in struct stat the
> utime() syscall is kind of obsolete. It's not possible anymore to
> restore the exact access/modification time of a file.
Replying to myself: utimes() is already available, on some
architectures. The question is why not for archs != alpha, ia64, PA, SPARC?
And of course the question of futimes/lutimes remains.
- --
- --------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/D56a2ijCOnn/RHQRAv9iAJ4iMFqoMSag+z09me48eEImg0I6pgCfacBt
WQMXcYFT2+9SGv9zbU3UZX0=
=dpAI
-----END PGP SIGNATURE-----
Ulrich Drepper <[email protected]> wrote:
>
> If
> there are filesystems which store the sub-seconds on disk I think this
> is necessary since otherwise all kinds of programs (including archives)
> cannot be written correctly. If the sub-seconds only live in memory I
> still think it would be good to have the syscalls but it would not be
> that urgent.
XFS (at least) stores nanoseconds on disk. So yes, I think we should make
this change.
>>>>> On Fri, 11 Jul 2003 22:37:30 -0700, Ulrich Drepper <[email protected]> said:
Uli> Replying to myself: utimes() is already available, on some
Uli> architectures. The question is why not for archs != alpha,
Uli> ia64, PA, SPARC?
Do you have this backwards? ia64 has utimes(), but not utime(). The
same should be true for Alpha.
--david
--- linux-2.5/arch/i386/kernel/entry.S-old 2003-07-07 15:56:22.000000000 -0700
+++ linux-2.5/arch/i386/kernel/entry.S 2003-07-11 22:46:02.000000000 -0700
@@ -876,6 +876,7 @@ ENTRY(sys_call_table)
.long sys_clock_nanosleep
.long sys_statfs64
.long sys_fstatfs64
- .long sys_tgkill
+ .long sys_tgkill /* 270 */
+ .long sys_utimes
nr_syscalls=(.-sys_call_table)/4
--- linux-2.5/include/asm-i386/unistd.h-old 2003-07-07 15:56:22.000000000 -0700
+++ linux-2.5/include/asm-i386/unistd.h 2003-07-11 22:45:21.000000000 -0700
@@ -276,8 +276,9 @@
#define __NR_statfs64 268
#define __NR_fstatfs64 269
#define __NR_tgkill 270
+#define __NR_utimes 271
-#define NR_syscalls 271
+#define NR_syscalls 272
/* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
Andrew Morton writes:
> Ulrich Drepper <[email protected]> wrote:
> >
> > If
> > there are filesystems which store the sub-seconds on disk I think this
> > is necessary since otherwise all kinds of programs (including archives)
> > cannot be written correctly. If the sub-seconds only live in memory I
> > still think it would be good to have the syscalls but it would not be
> > that urgent.
>
> XFS (at least) stores nanoseconds on disk. So yes, I think we should make
> this change.
so does reiser4.
> -
Nikita.
> [[email protected]]
>
> so does reiser4.
Speaking of which, when is reiser4 going to be ready?
--
Tomas Szepe <[email protected]>
Tomas Szepe writes:
> > [[email protected]]
> >
> > so does reiser4.
>
> Speaking of which, when is reiser4 going to be ready?
Real soon now.
Latest benchmark results are available at the
http://namesys.com/intbenchmarks/mongo/03.07.11.light/short.html
we still have problems with delete performance, but in three to ten days
reiser4 will be released to the public testing.
>
> --
> Tomas Szepe <[email protected]>
Nikita.