Skip to contentSkip to conversation

utimes/futimes/lutimes syscalls

DISCUSSION Ulrich Drepper 5 participants 8 messages Jul 12, 2003 – Jul 15, 2003

lore
Share & tools
lore

Ulrich Drepper

author
#0 lore raw

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

author
#1 lore raw

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

Quoted 3 lines · Ulrich Drepper

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

#4 lore raw
In reply to Ulrich Drepper
Quoted 7 lines · Ulrich Drepper

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.

#2 lore raw
In reply to Ulrich Drepper
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Ulrich Drepper

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
author
#3 lore raw

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

Quoted 2 lines · David Mosberger

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

arch/i386/kernel/entry.S renamed from arch/i386/kernel/entry.S-old +2 -1
@@ -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
include/asm-i386/unistd.h renamed from include/asm-i386/unistd.h-old +2 -1
@@ -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> */
#5 lore raw
In reply to Andrew Morton
Quoted 11 lines · Andrew Morton
Quoted 7 lines · Ulrich Drepper

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.

Quoted 1 line

-

Nikita.

#7 lore raw
Quoted 5 lines · Tomas Szepe
Quoted 3 lines

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

Quoted 3 lines
Signature · 2 lines
-- 
Tomas Szepe <[email protected]>

Nikita.