[1003.1(2016)/Issue7+TC2 0001118]: Clarify meaning of "file lock"
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1118 == Reported By:rpalethorpe Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1118 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: Resolved Name: Richard Palethorpe Organization: SUSE User Reference: Section:fork, fcntl, flockfile Page Number:fork Line Number:20ish Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=1118#c4061 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2017-01-20 13:05 UTC Last Modified: 2018-07-26 16:42 UTC == Summary:Clarify meaning of "file lock" == Relationships ID Summary -- related to 0001112 mutex/rwlock ownership after fork is un... == -- (0004063) shware_systems (reporter) - 2018-07-26 16:42 http://austingroupbugs.net/view.php?id=1118#c4063 -- Additional note based on phone discussion: page 497 line 17271: Note that after a fork( ), two handles (Ed: either file descriptor or FILE * in this context) exist where one existed before. The application shall ensure that, if both handles can ever be accessed, they are both in a state where the other could become the active handle first. The application shall prepare for a fork( ) exactly as if it were a change of active handle. (If the only action performed by one of the processes is one of the exec functions or _exit( ) (not exit( )), the handle is never accessed in that process.) This apparently includes it being the application's responsibility to unlock any locks established by fcntl() or f(try)lockfile() on the stream, whether the application is single or multi-threaded, before attempting the call to fork() so either parent or child process may establish a new lock without blocking, if desired, and otherwise the behavior is undefined. Issue History Date ModifiedUsername FieldChange == 2017-01-20 13:05 rpalethorpeNew Issue 2017-01-20 13:05 rpalethorpeName => Richard Palethorpe 2017-01-20 13:05 rpalethorpeOrganization => SUSE 2017-01-20 13:05 rpalethorpeSection => fork, fcntl, flockfile 2017-01-20 13:05 rpalethorpePage Number => fork 2017-01-20 13:05 rpalethorpeLine Number => 20ish 2017-01-20 14:36 rpalethorpeNote Added: 0003558 2018-07-26 15:11 nick Relationship added related to 0001112 2018-07-26 16:06 geoffclare Note Added: 0004061 2018-07-26 16:07 geoffclare Interp Status => --- 2018-07-26 16:07 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1118#c4061 2018-07-26 16:07 geoffclare Status New => Resolved 2018-07-26 16:07 geoffclare Resolution Open => Accepted As Marked 2018-07-26 16:08 geoffclare Tag Attached: tc3-2008 2018-07-26 16:42 shware_systems Note Added: 0004063 ==
[1003.1(2016)/Issue7+TC2 0001119]: When the file named by the operand does not exist, `file` should not exit with zero status
The following issue has been CLOSED. == http://austingroupbugs.net/view.php?id=1119 == Reported By:mhjacobson Assigned To:ajosey == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1119 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Closed Name: Matt Jacobson Organization: User Reference: Section:file Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: Resolution: Rejected Fixed in Version: == Date Submitted: 2017-02-15 01:48 UTC Last Modified: 2018-07-26 16:26 UTC == Summary:When the file named by the operand does not exist, `file` should not exit with zero status == Issue History Date ModifiedUsername FieldChange == 2017-02-15 01:48 mhjacobson New Issue 2017-02-15 01:48 mhjacobson Status New => Under Review 2017-02-15 01:48 mhjacobson Assigned To => ajosey 2017-02-15 01:48 mhjacobson Name => Matt Jacobson 2017-02-15 01:48 mhjacobson Section => file 2017-02-15 01:48 mhjacobson Page Number => 0 2017-02-15 01:48 mhjacobson Line Number => 0 2017-02-21 01:55 Vincent LefevreNote Added: 0003563 2017-02-21 12:06 joerg Note Added: 0003564 2017-02-21 14:07 shware_systems Note Added: 0003565 2017-02-21 14:19 shware_systems Note Edited: 0003565 2017-02-22 01:16 Vincent LefevreNote Added: 0003566 2017-02-23 18:51 shware_systems Note Added: 0003569 2017-02-23 18:55 shware_systems Note Edited: 0003569 2017-02-23 19:05 shware_systems Note Edited: 0003569 2017-02-27 09:50 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016)/Issue7+TC2 2018-07-26 16:26 Don Cragun Note Added: 0004062 2018-07-26 16:26 Don Cragun Interp Status => --- 2018-07-26 16:26 Don Cragun Status Under Review => Closed 2018-07-26 16:26 Don Cragun Resolution Open => Rejected ==
[1003.1(2016)/Issue7+TC2 0001119]: When the file named by the operand does not exist, `file` should not exit with zero status
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1119 == Reported By:mhjacobson Assigned To:ajosey == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1119 Category: Shell and Utilities Type: Enhancement Request Severity: Objection Priority: normal Status: Under Review Name: Matt Jacobson Organization: User Reference: Section:file Page Number:0 Line Number:0 Interp Status: --- Final Accepted Text: == Date Submitted: 2017-02-15 01:48 UTC Last Modified: 2018-07-26 16:26 UTC == Summary:When the file named by the operand does not exist, `file` should not exit with zero status == -- (0004062) Don Cragun (manager) - 2018-07-26 16:26 http://austingroupbugs.net/view.php?id=1119#c4062 -- This was discussed during the July 26, 2018 conference call. This change request is rejected... The file utility is unlike other file-handling utilities in that when a file does not exist, its non-existence is a piece of information about the file which file writes to standard output. The exit status of zero indicates that this information was successfully written to standard output. Other utilities report the non-existence to standard error and the exit status indicates that an error message was written to standard error. Issue History Date ModifiedUsername FieldChange == 2017-02-15 01:48 mhjacobson New Issue 2017-02-15 01:48 mhjacobson Status New => Under Review 2017-02-15 01:48 mhjacobson Assigned To => ajosey 2017-02-15 01:48 mhjacobson Name => Matt Jacobson 2017-02-15 01:48 mhjacobson Section => file 2017-02-15 01:48 mhjacobson Page Number => 0 2017-02-15 01:48 mhjacobson Line Number => 0 2017-02-21 01:55 Vincent LefevreNote Added: 0003563 2017-02-21 12:06 joerg Note Added: 0003564 2017-02-21 14:07 shware_systems Note Added: 0003565 2017-02-21 14:19 shware_systems Note Edited: 0003565 2017-02-22 01:16 Vincent LefevreNote Added: 0003566 2017-02-23 18:51 shware_systems Note Added: 0003569 2017-02-23 18:55 shware_systems Note Edited: 0003569 2017-02-23 19:05 shware_systems Note Edited: 0003569 2017-02-27 09:50 geoffclare Project 1003.1(2008)/Issue 7 => 1003.1(2016)/Issue7+TC2 2018-07-26 16:26 Don Cragun Note Added: 0004062 ==
[1003.1(2016)/Issue7+TC2 0001118]: Clarify meaning of "file lock"
The following issue has been RESOLVED. == http://austingroupbugs.net/view.php?id=1118 == Reported By:rpalethorpe Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1118 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: Resolved Name: Richard Palethorpe Organization: SUSE User Reference: Section:fork, fcntl, flockfile Page Number:fork Line Number:20ish Interp Status: --- Final Accepted Text:http://austingroupbugs.net/view.php?id=1118#c4061 Resolution: Accepted As Marked Fixed in Version: == Date Submitted: 2017-01-20 13:05 UTC Last Modified: 2018-07-26 16:07 UTC == Summary:Clarify meaning of "file lock" == Relationships ID Summary -- related to 0001112 mutex/rwlock ownership after fork is un... == Issue History Date ModifiedUsername FieldChange == 2017-01-20 13:05 rpalethorpeNew Issue 2017-01-20 13:05 rpalethorpeName => Richard Palethorpe 2017-01-20 13:05 rpalethorpeOrganization => SUSE 2017-01-20 13:05 rpalethorpeSection => fork, fcntl, flockfile 2017-01-20 13:05 rpalethorpePage Number => fork 2017-01-20 13:05 rpalethorpeLine Number => 20ish 2017-01-20 14:36 rpalethorpeNote Added: 0003558 2018-07-26 15:11 nick Relationship added related to 0001112 2018-07-26 16:06 geoffclare Note Added: 0004061 2018-07-26 16:07 geoffclare Interp Status => --- 2018-07-26 16:07 geoffclare Final Accepted Text => http://austingroupbugs.net/view.php?id=1118#c4061 2018-07-26 16:07 geoffclare Status New => Resolved 2018-07-26 16:07 geoffclare Resolution Open => Accepted As Marked ==
[1003.1(2016)/Issue7+TC2 0001118]: Clarify meaning of "file lock"
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1118 == Reported By:rpalethorpe Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1118 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Richard Palethorpe Organization: SUSE User Reference: Section:fork, fcntl, flockfile Page Number:fork Line Number:20ish Interp Status: --- Final Accepted Text: == Date Submitted: 2017-01-20 13:05 UTC Last Modified: 2018-07-26 16:06 UTC == Summary:Clarify meaning of "file lock" == Relationships ID Summary -- related to 0001112 mutex/rwlock ownership after fork is un... == -- (0004061) geoffclare (manager) - 2018-07-26 16:06 http://austingroupbugs.net/view.php?id=1118#c4061 -- On page 60 line 1795 section 3 add a new subsection:3.168 File Lock A lock obtained on a file through the use of fcntl() or lockf().and renumber the later 3.x subsections. On page 874 after line 29515, add to flockfile APPLICATION USAGE:Note: a FILE lock is not a file lock (see XREF to XBD 3.168). On page 875 line 29518 section flockfile(), change:acquire a file lockto:acquire a FILE lock Issue History Date ModifiedUsername FieldChange == 2017-01-20 13:05 rpalethorpeNew Issue 2017-01-20 13:05 rpalethorpeName => Richard Palethorpe 2017-01-20 13:05 rpalethorpeOrganization => SUSE 2017-01-20 13:05 rpalethorpeSection => fork, fcntl, flockfile 2017-01-20 13:05 rpalethorpePage Number => fork 2017-01-20 13:05 rpalethorpeLine Number => 20ish 2017-01-20 14:36 rpalethorpeNote Added: 0003558 2018-07-26 15:11 nick Relationship added related to 0001112 2018-07-26 16:06 geoffclare Note Added: 0004061 ==
[1003.1(2016)/Issue7+TC2 0001118]: Clarify meaning of "file lock"
The following issue has been set as RELATED TO issue 0001112. == http://austingroupbugs.net/view.php?id=1118 == Reported By:rpalethorpe Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1118 Category: Base Definitions and Headers Type: Clarification Requested Severity: Comment Priority: normal Status: New Name: Richard Palethorpe Organization: SUSE User Reference: Section:fork, fcntl, flockfile Page Number:fork Line Number:20ish Interp Status: --- Final Accepted Text: == Date Submitted: 2017-01-20 13:05 UTC Last Modified: 2018-07-26 15:11 UTC == Summary:Clarify meaning of "file lock" == Relationships ID Summary -- related to 0001112 mutex/rwlock ownership after fork is un... == Issue History Date ModifiedUsername FieldChange == 2017-01-20 13:05 rpalethorpeNew Issue 2017-01-20 13:05 rpalethorpeName => Richard Palethorpe 2017-01-20 13:05 rpalethorpeOrganization => SUSE 2017-01-20 13:05 rpalethorpeSection => fork, fcntl, flockfile 2017-01-20 13:05 rpalethorpePage Number => fork 2017-01-20 13:05 rpalethorpeLine Number => 20ish 2017-01-20 14:36 rpalethorpeNote Added: 0003558 2018-07-26 15:11 nick Relationship added related to 0001112 ==