utimes/futimes/lutimes syscalls

utimes/futimes/lutimes syscalls

[Ulrich Drepper]

-----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-----

Re: utimes/futimes/lutimes syscalls

[Ulrich Drepper]

-----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-----

Re: utimes/futimes/lutimes syscalls

[Andrew Morton]

Ulrich Drepper <drepper@redhat.com> 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.

Re: utimes/futimes/lutimes syscalls

[David Mosberger]

>>>>> On Fri, 11 Jul 2003 22:37:30 -0700, Ulrich Drepper <drepper@redhat.com> 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

Re: utimes/futimes/lutimes syscalls

[Ulrich Drepper]

[-- Attachment #1: Type: text/plain, Size: 694 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Mosberger wrote:

> Do you have this backwards?  ia64 has utimes(), but not utime().  The
> same should be true for Alpha.

Yes, it was meant to say "why not for archs *other than* ...".

I attach the x86 version of the change.

- --
- --------------.                        ,-.            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/D6z/2ijCOnn/RHQRAl8uAKClUPu1rNyaND4F90tZB1+y9+IfAgCfcs49
ihs1EesN3+egIbHHdE00H2c=
=HK+M
-----END PGP SIGNATURE-----

[-- Attachment #2: d-kernel-utimes --]
[-- Type: text/plain, Size: 799 bytes --]

--- 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> */
 

Re: utimes/futimes/lutimes syscalls

[Nikita Danilov]

Andrew Morton writes:
 > Ulrich Drepper <drepper@redhat.com> 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.

Re: utimes/futimes/lutimes syscalls

[Tomas Szepe]

> [Nikita@Namesys.COM]
> 
> so does reiser4.

Speaking of which, when is reiser4 going to be ready?

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: utimes/futimes/lutimes syscalls

[Nikita Danilov]

Tomas Szepe writes:
 > > [Nikita@Namesys.COM]
 > > 
 > > 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 <szepe@pinerecords.com>

Nikita.