Minutes of the 16th June 2022 Teleconference    Austin-1229 Page 1 of 1
Submitted by Andrew Josey, The Open Group.       18th June 2022

Attendees:
    Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
    Mark Ziegast, SHware Systems Dev.
    Don Cragun, IEEE PASC OR
    Geoff Clare, The Open Group
    Andrew Josey, The Open Group

Apologies
    Eric Ackermann, HPI, University of Potsdam
    Eric Blake, Red Hat, The Open Group OR
    Tom Thompson, IEEE

* General news

This was a call dedicated to general bugs.


* Outstanding actions

Bug 1533: struct tm: add tm_gmtoff (and tm_zone) field(s) OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1533
This was discussed in the February 3, 2022 teleconference. 
Leave it open until we get a more complete suggestion for the Desired
Action.


* Current Business


Bug 1560: clarify wording of command substitution OPEN
https://austingroupbugs.net/view.php?id=1560

Leave this and related bugs 1561, and 1564 open pending reviews/discussions.

We continued working through the outstanding issues list:

Bug 657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified   OPEN
https://austingroupbugs.net/view.php?id=657

Outstanding action still on Eric B.  Expand to get feedback from
Solaris and BSD.


Bug 0000251: Forbid newline, or even bytes 1 through 31 (inclusive), in filenames  OPEN
http://austingroupbugs.net/view.php?id=251

Don has an action to produce a proposal.


Bug 658: Undefined/unspecified behavior clauses in description of open have race conditions Accepted as Marked
https://austingroupbugs.net/view.php?id=658

This item is tagged for TC3-2008.

At 2008 edition page 1379 line 45181 [XSH open DESCRIPTION O_EXEC], change:

The result is unspecified if this flag is applied to a directory.
to:
If path names a directory, it is unspecified whether open() fails,
or whether the directory is opened but with an unspecified access
mode.

At 2008 edition page 1379 line 45184 [XSH open DESCRIPTION O_RDWR], change:

The result is undefined if this flag is applied to a FIFO.
to:
If path names a FIFO, and the implementation does not support opening
a FIFO for simultaneous read and write, then open() shall fail.

At 2008 edition page 1379 line 45186 [XSH open DESCRIPTION O_SEARCH], change:

The result is unspecified if this flag is applied to a non-directory
file.
to:
If path names a non-directory file, it is unspecified whether open()
fails, or whether the file is opened but with an unspecified access
mode.

After 2008 edition page 1379 line 45188 [XSH open DESCRIPTION], add a new paragraph:

If a file is successfully opened with an unspecified access mode,
an application can use fcntl() to discover the access mode that
was selected.

At 2008 edition page 1382 line 45311 [XSH open ERRORS], change the following:

<SIO>[EINVAL] The implementation does not support synchronized I/O for
this file.</SIO>
to: (SIO shading applies only to the existing text, as noted):
[EINVAL] The path argument names a FIFO and O_RDWR was specified, but
the implementation considers this an error; <SIO>or synchronized I/O
flags were specified and the implementation does not support
synchronized I/O for the file.</SIO>

At 2018 edition page 1411 line 46908 [XSH open ERRORS EISDIR], change:

The named file is a directory and oflag includes O_WRONLY or O_RDWR, or
includes O_CREAT without O_DIRECTORY.
to:
The named file is a directory and oflag includes O_WRONLY or O_RDWR, or
includes O_CREAT without O_DIRECTORY, or includes O_EXEC when O_EXEC
is not the same value as O_SEARCH.

At 2018 edition page 1412 line 46934 [XSH open ERRORS ENOTDIR], change:

... link to a directory; or O_DIRECTORY was specified and the path argument
resolves to a non-directory file.

to:

... link to a directory; or O_DIRECTORY was specified and the path argument
names a non-directory file; or the path argument names a non-directory file and
O_SEARCH was specified when O_SEARCH is not the same value as O_EXEC.

At 2008 edition page 1385 line 45430 [XSH open RATIONALE], change:

Since FIFOs could be implemented in other ways, and since two file
descriptors can be used to the same effect, this possibility is
left as undefined.

to:

Since FIFOs could be implemented in other ways, and since two file
descriptors can be used to the same effect, an implementation is
allowed to reject the use of O_RDWR on a FIFO.

At 2008 edition page 1385 line 45452 [XSH open RATIONALE], after "need not be
distinct", add a sentence:

Although the standard allows open() to fail on an attempt to use
O_EXEC on a directory, or O_SEARCH on a non-directory, this is only
possible in implementations where the two modes have distinct values. 


Bug 0000672: Necessary step(s) to synchronize filename operations on disk  Accepted as Marked
https://austingroupbugs.net/view.php?id=672

This item is tagged for Issue 8

Page and line numbers are for the 2013 edition.

Changes to XBD...

After page 94 line 2613, insert a new paragraph:

  For the purpose of this definition, an operation that reads or
  searches a directory is considered to be a read operation, an
  operation that modifies a directory is considered to be a write
  operation, and a directory's entries are considered to be the data
  read or written.

  The standard provides no way to synchronize the contents or
  attributes of a symbolic link.

After page 107 line 2884 add a new XBD 4.2 section (and renumber the
current 4.2 and all later 4.x sections):

  4.2 Directory Operations

  All file system operations that read or search a directory or that
  modify the contents of a directory (for example creating,
  unlinking, or renaming a file) shall operate atomically. That is,
  each operation shall either have its entire effect and succeed, or
  shall not affect the file system and shall fail. Furthermore,
  these operations shall be serializable; that is, the state of the
  file system and of the results of each operation shall always be
  values that would be obtained if the operations were executed one
  after the other.

After page 107 line 2939 add a new XBD 4.8 section (and renumber
the remaining 4.x sections):

  4.8 File System Cache

  If the file system is accessed via a memory cache, file-related
  requirements stated in the rest of this standard shall apply to
  the cache, except where explicitly stated otherwise: this
  includes directory atomicity and serializability requirements (see
  XBD 4.2), file times update requirements (see XBD 4.10), and
  read-write serializability requirements (see write()). Cache entries
  shall be transferred to the underlying storage as the result of
  successful calls to fdatasync(), fsync(), or aio_fsync(), and may be
  transferred to storage automatically at other times. Such transfers
  shall be atomic, with minimum units being directory entries (for
  directory contents), aligned data blocks of the fundamental file
  system block size (for regular-file contents; see <sys/statvfs.h>),
  and all attributes of a single file (for file attributes).

  <small>Note: If the system crashes before the cache is fully
       transferred, later operations' effects may be present in
       storage with earlier effects missing.</small>

  <small>Note: Operations that create or modify multiple directory
       entries, aligned data blocks, or file attributes (e.g., mkdir(),
       rename(), write() with large buffer size, open() with O_CREAT)
       may have only part of their effects transferred to storage, and
       after a crash these operations may appear to have been only
       partly done, with the parts not necessarily done in any
       order. For example, only the second half of a write() may be
       transferred; or rename("a","b") may result in "b" being created
       without "a" being removed.</small>

  <small>Note: Although conforming file systems are required to
       perform all caching as described above, some file systems may
       support non-conforming configurations (for example via mount
       options) for which this is not the case. Applications that are
       used on non-conforming file systems cannot rely on files being
       synchronized properly.</small>

Changes to XSH...

At page 579 line 19973 section aio_fsync() change the APPLICATION
USAGE section from:

   None.

to:

   Refer to fdatasync() and fsync().

At page 821 line 27587 section fdatasync() change the APPLICATION
USAGE section from:

   None.

to:

   An application that modifies a directory, e.g., by creating a file
   in the directory, can invoke fdatasync() on the directory to
   ensure that the directory's entries are synchronized, although
   for most applications this should not be necessary (see XBD 4.8).

After page 963 line 32522 section fsync() add a new paragraph to the
APPLICATION USAGE section:

   An application that modifies a directory, e.g., by creating a file
   in the directory, can invoke fsync() on the directory to ensure
   that the directory's entries and file attributes are synchronized.
   For most applications, synchronizing the directory's entries should
   not be necessary (see XBD 4.8).


Changes to XRAT...

After page 3472 line 117096 add new XRAT A.4.2 and A.4.8 sections (and
renumber the current A.4.2 and all later A.4.x sections).

   A.4.2 Directory Operations

   Earlier versions of this standard did not make clear that
   directory modifications are performed atomically and serially,
   although that is the historical behavior and was always intended.

   A.4.8 File System Cache

   Earlier versions of this standard did not specify the behavior of
   aio_fsync(), fdatasync() or fsync() on directories, nor did they
   specify constraints on the underlying storage in the absence of
   calls to aio_fsync, fdatasync() or fsync().

   Although directory operations are atomic and serializable, they
   are not necessarily durable. An application that requires a
   directory modification to be durable should use fdatasync() or
   fsync() (or aio_fsync()) on the directory. However, the intention
   of the requirements for directory modifications is that most
   applications should not need to do this. For example, a common
   method of updating a file is to create a new temporary file, call
   fdatasync() or fsync() to synchronize the new file, and then use
   rename() to replace the old file with the new file. If a crash
   occurs after the rename(), then the file being updated will have
   either its old contents or its new contents on the storage device
   when the system is rebooted. An application needs to synchronize
   the directory only if it wants to be sure the updated file will
   have its new contents on the storage device.

   Some operations, such as rename(), can affect more than one
   directory, whereas synchronization calls such as fsync() can affect
   at most one directory at a time. Two calls to fsync() may be
   needed after a rename() to ensure its durability.

   If the file system is inconsistent after a crash it is usually
   automatically checked and repaired when the system is rebooted, or
   can be repaired manually using a utility such as fsck.

   If an unrecoverable I/O error occurs when cache is transferred to
   storage, this standard provides no way for applications to discover
   the error reliably. Implementations are encouraged to report such
   errors on subsequent reads of the storage.


Bug 0000696: either NAME_MAX shouldn't be optional, or readdir_r() needs clarification  Accepted as Marked
http://www.austingroupbugs.net/view.php?id=696

All page and line numbers refer to 202x D2.1.

On page 501 line 17715 section 2.9.1, remove readdir() from the list of non-thread-safe functions

On page 501 line 17737 section 2.9.1, append:
    The readdir() function need not be thread-safe if concurrent
    calls are made for the same directory stream.


Shade P219, L7616-7617 (<dirent.h> readdir_r() declaration) with OB shading.

Shade P1724, L56494-56495 (readdir_r() SYNOPSIS) with OB shading.

Change P1724, L56528 (readdir() DESCRIPTION) from:
    The readdir() function need not be thread-safe.
to:
    The readdir() function need not be thread-safe if concurrent
    calls are made for the same directory stream.

Add after P1725, L56555 (readdir() ERRORS):
    [ENOMEM] Insufficient memory is available.

Add new paragraph after P1725, L56944 (readdir() RATIONALE):
    Since the size of a filename has no limit on some filesystem
    types, there is no way to reliably allocate a buffer large
    enough to hold a filename being returned by readdir_r().
    Therefore, readdir_r() has been marked obsolescent and readdir()
    is now required to be thread safe as long as there are no
    concurrent calls to it on a single stream.

Bug 906: Ambiguity of abort() behavior racing with sigaction OPEN
https://austingroupbugs.net/view.php?id=906

We will continue on this item next time


Next Steps
----------

The next calls are on:
    Mon 2022-06-20 (gettext)
    Thu 2022-06-23 (general bugs)


The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net


An etherpad is usually up for the meeting, with a URL using the date format as below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)