Messages in this thread | | | Date | Wed, 3 Sep 2008 15:48:40 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] INITRAMFS: Add option to preserve mtime from INITRAMFS cpio images |
| |
On Wed, 3 Sep 2008 15:41:31 -0700 Nye Liu <nyet@nyet.org> wrote:
> > > collected[N_ALIGN(name_len) + body_len] = '\0'; > > > clean_path(collected, 0); > > > sys_symlink(collected + N_ALIGN(name_len), collected); > > > sys_lchown(collected, uid, gid); > > > + do_lutime(collected, &mtime); > > > state = SkipIt; > > > next_state = Reset; > > > return 0; > > > @@ -466,6 +520,7 @@ static char * __init unpack_to_rootfs(char *buf, unsigned len, int check_only) > > > buf += inptr; > > > len -= inptr; > > > } > > > + dir_utime(); > > > > Perhaps this is the simplest implementation - I didn't check the fine > > details. What's your thinking here? > > > > The main problem is that i need to save off the entire list for later > processing of the directory mtimes... if i process the directory mtimes > in the same pass as the file/link mtimes, touching the directory inode > when creating/modifying the file/links updates the directory mtime, and > overwrites whatever mtime i set the directory to when i created it. > > The only solution is to do a two pass, which is why the list is > necessary. If there is a better way, i did not find it :( > > It could be that i misunderstood your question though :)
I'm wondering whether this code need to use `struct utimbuf' at all. Or at least, as much as it does. utimbuf is more a userspace-facing thing whereas in-kernel timespecs and timevals are more common.
The code as you have it does a fair few conversions into utimbuf format (both directly and via the existing functions which it calls). Would it be simpler if it dealt in terms of timespecs?
| |