All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org
To: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: [Bug 26022] New: futimesat and utimensat handle NULL filenames
Date: Sun, 2 Jan 2011 02:44:27 GMT	[thread overview]
Message-ID: <bug-26022-11311@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=26022

           Summary: futimesat and utimensat handle NULL filenames
           Product: Documentation
           Version: unspecified
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: man-pages
        AssignedTo: documentation_man-pages-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
        ReportedBy: vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org
        Regression: No


if you pass futimesat or utimensat a NULL path, the functions will operate on
the fd as given.  in which case it can be either a fd for a directory or a
file.

for example, the two calls to futimesat() below will do the same thing:
#include <fcntl.h>
#include <stdio.h>
int main() {
    int fd = open("f", O_CREAT|O_RDWR, 0777);
    printf("futimesat = %i\n", futimesat(fd, NULL, NULL));
    printf("futimesat = %i\n", futimesat(AT_FDCWD, "f", NULL));
    return 0;
}

same behavior can be observed with utimensat(), but it seems only at the Linux
syscall level.  the POSIX/C library level will reject a NULL filename with
errno==EINVAL, but the Linux kernel will treat the dirfd as an fd.  funny
enough, while glibc rejects pathname==NULL at its ABI, it relies on the Linux
ABI to accept pathname==NULL while implementing other functions.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2011-01-02  2:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-02  2:44 bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r [this message]
     [not found] ` <bug-26022-11311-3bo0kxnWaOQUvHkbgXJLS5sdmw4N0Rt+2LY78lusg7I@public.gmane.org/>
2014-01-22 13:05   ` [Bug 26022] futimesat and utimensat handle NULL filenames bugzilla-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r

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=bug-26022-11311@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon-590eeb7gvniway/ihj7yzeb+6bgklq7r@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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.