From: Ulrich Drepper <drepper@redhat.com>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-man@vger.kernel.org
Subject: Re: [PATCH] utimensat() non-conformances and fixes
Date: Sun, 20 Apr 2008 23:20:43 -0700 [thread overview]
Message-ID: <480C323B.3060608@redhat.com> (raw)
In-Reply-To: <47FA9DA1.8040508@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kerrisk wrote:
> 1. The draft POSIX.1-200x specification for utimensat() says that if a
> times[n].tv_nsec field is UTIME_OMIT or UTIME_NOW, then the value in the
> corresponding tv_sec field is ignored. However the current Linux
> implementation requires the tv_sec value to be zero (or the EINVAL error
> results). This requirement should be removed.
OK, for now. I think the implemented behavior is better, though.
> However, the current implementation does not generate
> EPERM if one tv_nsec field is UTIME_NOW while the other is UTIME_OMIT -- it
> should give this error for that case.
This is probably a necessary change. Non-synchronized changes might be
a security problem.
> However, in
> the same circumstances, when utimensat() is given a 'times' array in which
> both tv_nsec fields are UTIME_NOW, which provides equivalent functionality
> to specifying 'times' as NULL, the call succeeds. I think that it should fail
> with the error EACCES in this case.
I guess so.
> (times == NULL && times[0].tv_nsec == UTIME_NOW && times[1].tv_nsec ==
> UTIME_NOW)
>
> case should be treated like the traditional utimes() case where 'times'
> is NULL. That is, the call should succeed for a file marked append-only
> and should give the error EACCES if the file is marked as immutable.
Is this something I changed? I doubt I added this.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkgMMjsACgkQ2ijCOnn/RHT9dwCgxhprkeAg86sW11ilKtHaVYtO
Ae0An18utIREI/MnfwPO5HixxZbJz7zD
=hrvK
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-04-21 6:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-07 22:18 [PATCH] utimensat() non-conformances and fixes Michael Kerrisk
2008-04-07 22:18 ` Michael Kerrisk
[not found] ` <47FA9DA1.8040508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-04-17 18:06 ` Michael Kerrisk
2008-04-17 18:06 ` Michael Kerrisk
2008-04-23 9:37 ` Miklos Szeredi
2008-04-23 9:37 ` Miklos Szeredi
2008-04-21 6:20 ` Ulrich Drepper [this message]
[not found] ` <480C323B.3060608-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2008-04-21 15:41 ` Michael Kerrisk
2008-04-21 15:41 ` Michael Kerrisk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=480C323B.3060608@redhat.com \
--to=drepper@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--cc=mtk.manpages@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.