utime kernel patch fixed

utime kernel patch fixed

Post by a.vign.. » Tue, 15 Jul 1997 04:00:00


There are two bugs in the utime kernel patch for 2.1.43 you can find at
    http://hegel.ittc.ukans.edu/projects/utime/ :

1) speed is improperly calculated, seems that 1 is blindly added without
   further checks. My P5-100 and 150 give values of 101000000 and
   151000000 respectively.

2) there is a bug in nanosleep, a modulo should really be a div:

diff -u -r -N -b --exclude-from=diff_exclude linux-ref/kernel/sched.c linux-work/kernel/sched.c
--- linux-ref/kernel/sched.c    Thu Jun 12 18:22:10 1997

                return -EINTR;
+       expire = t.tv_sec*HZ+jiffies;
+       expire_u = t.tv_nsec/1000+jiffies_u;
+       expire += expire_u % USEC_PER_JIFFIES;
should be:
+       expire += expire_u / USEC_PER_JIFFIES;
+       expire_u %= USEC_PER_JIFFIES;
+       current->timeout = expire;
+       current->timeout_u = expire_u;
+       current->state = TASK_INTERRUPTIBLE;
+       schedule();
+       if ((expire > jiffies)||((expire==jiffies)
+                                && (expire_u > jiffies_u))) {
+                if (rmtp) {
+                        t.tv_sec = (expire-jiffies)/HZ;
+                        t.tv_nsec = (expire-jiffies)%HZ +
+                                (expire_u-jiffies_u)*1000;
+                        if (copy_to_user(rmtp, &t,
+                                         sizeof(struct timespec)))
+                                return -EFAULT;
+                }
+                return -EINTR;
+       }
        return 0;

Note for dosemu developers: this patch doesn't change _anything_.



1. utime vs utimes

My application is sort of a backup program. It stores a file's contents
in a database along with its metadata (owner/mode/mtime/etc) on a server
machine. At some later time, if needed, the file is restored to its
original state.

I've realized the current implementation is throwing away any sub-second
resolution in the last-modified time. Some platforms store both seconds
and microseconds (or nanoseconds in the case of Solaris), but the
st_mtime member retrieved by stat() only has the seconds part.

So I'm looking for two things: (1) the most portable/standard way of
getting the micro/nano second part from the stat structure and (2) the
best way to set that metadata back onto the newly restored file.

For the 'get' part, it looks like there's no standard API. Looks like a
bunch of ugly ifdefs are required. Does anyone have a sample piece of
code that handles the major platforms or just shows the way?

The 'set' part raises a question about the intention of SUS. The utime()
function is in the standard but is explicitly limited to seconds (SUSv3:
"The times in the structure utimbuf are measured in seconds since the
Epoch."). The utimes() function is also in SUS and allows microsecond
resolution ("The times in the timeval structure are measured in seconds
and microseconds since the Epoch"), but this interface is marked LEGACY
with a usage note indicating "For applications portability, the utime()
function should be used instead of utimes()". I don't get it - why would
the more capable interface be retired in favor of a dumber one? Is there
a non-legacy interface that supersedes utimes() and support setting
sub-second timestamps?


2. How to install Linux on RAID 0 build on HPT370

3. don't allow utime()/utimes() on immutable/append-only files

4. Imprimante avec PCNFS 5.1 sous SOLARIS 2.5.1

5. utime & utimes & POSIX & portability

6. Matrox G450 eTV is good choie?

7. PATCH: fix ALi 32bitisms, fix ALi FIFO, fix ALi IRQ crash


9. fix big initramfs (was: [PATCH] gen_init_cpio fixes for 2.5.64)

10. 2.5.63-current fix Coverted -> Converted , was (Re: [PATCH] kernel source spellchecker)

11. Linux Kernel Patch v1.3.47 - Bug & Fix

12. inline-patches for Linux kernel (fix)

13. Patching Mandrake Kernel to fix i830 video problem