This update addresses an issue described in
https://bugzilla.kernel.org/show_bug.cgi?id=207345
In answer to my question, Paul Eggert noted:
> Where do I find it?
https://www.iana.org/time-zones
Look under "Latest version", which is 2020a.
Reported-by: Paul Eggert <eggert@cs.ucla.edu>
Reported-by: Marco Curreli <marcocurreli@tiscali.it>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The Linux man page for ptsname_r, when describing the behaviour
in the error case, is
- not consistent with the future POSIX standard (POSIX Issue 8).
- not consistent with musl libc.
Find attached a patch to
- keep it consistent with what glibc does,
- make it consistent with musl libc,
- make it consistent with the future POSIX standard (POSIX
Issue 8).
Details:
glibc's implementation of ptsname_r, when it fails, returns the
error code as return value AND sets errno. See
https://sourceware.org/git/?p=glibc.git;a=blob;f=login/ptsname.chttps://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/ptsname.chttps://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/ptsname.c
musl's implementation of ptsname_r, when it fails, returns the error code
but does NOT set errno. See
https://git.musl-libc.org/cgit/musl/tree/src/misc/pty.c
The proposal to add ptsname_r to POSIX, with text
"If successful, the ptsname_r( ) function shall return zero.
Otherwise, an error number shall be returned to indicate the
error."
has been accepted for inclusion in POSIX Issue 8.
http://austingroupbugs.net/view.php?id=508
Therefore a portable program should look at the return value from
ptsname_r, NOT the errno value. The current text in the man page
suggests to look at the errno value, which is wrong (because of
musl libc) and not future-proof (because of future POSIX).
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The page of attr(1) is relevant to xattrs, therefore add it to the
SEE ALSO section.
attr(1) command works for other filesystems as well.
Signed-off-by: Achilles Gaikwad <agaikwad@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Used Bird's source code, kernel source code, iproute2 source code
and iproute2 manpages to find meanings of these new attributes.
Signed-off-by: Jan Moskyto Matejka <mq@ucw.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See https://bugzilla.kernel.org/show_bug.cgi?id=198569.
Reported-by: Alexander Morozov <alexandermv@gmail.com>
Reported-by: Amir Goldstein <amir73il@gmail.com>
Reported-by: Jan Kara <jack@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Redundant because this is a Section 3 page, and the
text also describes the implementation in glibc.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From a conversation with Paul Eggert:
From: Paul Eggert <eggert@cs.ucla.edu>
Subject: Re: Errors in man pages, here: tzfile(5): Typo?
On 4/20/20 12:27 AM, Michael Kerrisk (man-pages) wrote:
> I think "UT" here is intended to mean "Universal Time", and as such
> should not be "UTC". Perhaps Paul can comment.
Yes, that's right. The tzfile format covers timestamps that predate the
introduction of UTC in 1960, so the documentation uses the sloppier and
more-general term "UT" instead of the more-precise term "UTC".
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document the details of the new FAN_DIR_MODIFY event, which
introduces entry name information to the fanotify event
reporting format.
Enhance the fanotify_fid.c example to also report this event.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
- The condition for printing "subdirectory created" was always
true.
- The arguments and error check of open_by_handle_at() were
incorrect.
- Fix example description inconsistencies.
- Nicer indentation of example output.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Some of the new event types that were added in v5.1 along with
init flag FAN_REPORT_FID are not eligible for reporting to a
directory watching with FAN_EVENT_ON_CHILD.
Document the events that cannot be generated on children of a
watching parent.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
It is not true that FAN_MARK_MOUNT cannot be used with a group
that was initialized with flag FAN_REPORT_FID.
The correct assertion is that events that require a group with
flag FAN_REPORT_FID cannot be requested on a mark mount.
For exaple, a FAN_OPEN event can be requested on a mark mount and
will generate an event with file handle information if the group
was initialized with flag FAN_REPORT_FID.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Matthew Bobrowski <mbobrowski@mbobrowski.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk