From: Carlos O'Donell <carlos@redhat.com>
To: Florian Weimer <fw@deneb.enyo.de>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: libc-alpha <libc-alpha@sourceware.org>
Subject: Re: [PATCH] manual: Add Descriptor-Relative Access section
Date: Mon, 11 May 2020 23:22:32 -0400 [thread overview]
Message-ID: <bdf15a66-2beb-6c61-a39a-cc4c2b76005a@redhat.com> (raw)
In-Reply-To: <87lfm8uf0u.fsf@mid.deneb.enyo.de>
On 5/4/20 7:16 AM, Florian Weimer wrote:
> * Michael Kerrisk:
>
>>> +@item
>>> +If a progrem wishes to access a directory tree which is being modified
>>> +concurrently, perhaps even by a different user on the system, the
>>> +program typically must avoid following symbolic links. With POSIX
>>> +interfaces, this can be done using the @code{O_NOFOLLOW} flag
>>> +(@pxref{Open-time Flags}) or the @code{AT_SYMLINK_FOLLOW} flag
>>> +(described below), but these flags affect only the final component of a
>>> +file name (the basename). Symbolic links in the parent directory part
>>> +are still followed. Therefore, without directory-relative access, it is
>>> +necessary to use the @code{fchdir} function to change the working
>>> +directory (@pxref{Working Directory}) and use the basename for file
>>> +system access. As explained before, this is not thread-safe. Keeping a
>>> +file descriptor of the directory is also required to be able to return
>>
>> Maybe better: s/of/that refers to/
>>
>>> +to it later, so descriptor-based access is a natural fit.
>>
>> s/descriptor-relativebased/descriptor-relative/ ?
>
> Thanks, we have now:
>
> […]
> directory (@pxref{Working Directory}) and use the basename for file
> system access. As explained before, this is not thread-safe. Keeping a
> file descriptor that refers to the directory is also required to be able
> to return to it later, so descriptor-relative access is a natural fit.
>
> 8<------------------------------------------------------------------8<
After much review I think that patchwork is working as intended here.
You must call your new patch v2 by changing the subject e.g. [PATCH v2] ...
All other comments on the thread are just that, comments on the patch.
--
Cheers,
Carlos.
next prev parent reply other threads:[~2020-05-12 3:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 9:30 Florian Weimer
2020-04-30 9:39 ` Andreas Schwab
2020-04-30 10:21 ` Florian Weimer
2020-04-30 10:32 ` Andreas Schwab
2020-04-30 11:01 ` Michael Kerrisk
2020-04-30 11:15 ` Michael Kerrisk
2020-04-30 11:35 ` Michael Kerrisk (man-pages)
2020-05-04 5:37 ` Florian Weimer
2020-05-04 8:38 ` Michael Kerrisk (man-pages)
2020-05-04 9:10 ` Florian Weimer
2020-05-04 10:02 ` Michael Kerrisk (man-pages)
2020-05-04 11:16 ` Florian Weimer
2020-05-06 15:48 ` Florian Weimer
2020-05-12 3:05 ` Carlos O'Donell
2020-05-12 3:10 ` Carlos O'Donell
2020-05-12 3:22 ` Carlos O'Donell [this message]
2020-05-12 3:35 ` Carlos O'Donell
2020-05-12 6:02 ` Michael Kerrisk
2020-05-12 7:19 ` Florian Weimer
2020-05-12 7:33 ` Michael Kerrisk (man-pages)
2020-04-30 9:32 Florian Weimer
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=bdf15a66-2beb-6c61-a39a-cc4c2b76005a@redhat.com \
--to=carlos@redhat.com \
--cc=fw@deneb.enyo.de \
--cc=libc-alpha@sourceware.org \
--cc=mtk.manpages@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).