From: "Adam J. Richter" <adam@yggdrasil.com>
Date: Sun, 2 Feb 2003 10:59:18 -0800
Message-Id: <200302021859.KAA11878@adam.yggdrasil.com>
To: linux-kernel@vger.kernel.org
Subject: Re: futimes()?
Cc: abramo.bagnara@libero.it, hpa@zytor.com
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1874
Lines: 38

>Abramo Bagnara wrote:
>"H. Peter Anvin" wrote:
>> 
>> In the general vein of avoiding security holes by using file
>> descriptors when doing repeated operations on the same filesystem
>> object, I have noticed that there doesn't seem to be a way to set
>> mtime using a file descriptor.  Do we need a futimes() syscall?
>
>Parallel to that, there is the long time needed lutimes() syscall.
>
>Who has never been annoyed that restoring a backup there's no way to
>restore former symlink mtime?

	I wonder if we could have an open flags similar to O_NOFOLLOW
that would allow a symbolic link to be "opened" just so it could
be referred to by f{stat,chown,chmod} so that programs that use this
style handle symbolic links the same way.

	Also, if you want to add another system call for setting stat
information, perhaps we could take the opportunity to reduce the
number of system calls per file being restored by programs like tar by
creating an fsetstat() system call that would take some kind of
extensible flags field so that programs like tar could do their
business in a single system call.  The kernel already seems to do this
internally through inode_operations.setattr.  (sys_chown -->
chown_common --> notify_change --> inode_setattr).  That way it
would be less likely that we'd have to add a new system calls again
if people think of new file attributes.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/