A NOTE has been added to this issue. ====================================================================== https://austingroupbugs.net/view.php?id=1824 ====================================================================== Reported By: dag-erling Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1824 Category: Shell and Utilities Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Dag-Erling Smørgrav Organization: User Reference: Section: Utilities Page Number: 2741-2748 Line Number: 90593-90715, 90876-90880 Final Accepted Text: ====================================================================== Date Submitted: 2024-04-01 15:31 UTC Last Modified: 2024-04-04 14:30 UTC ====================================================================== Summary: cp: directories and symlinks ======================================================================
---------------------------------------------------------------------- (0006737) geoffclare (manager) - 2024-04-04 14:30 https://austingroupbugs.net/view.php?id=1824#c6737 ---------------------------------------------------------------------- I believe the standard is clear on all of the points raised here. Taking the bullet items after "To summarize" in turn: - The rationale implies that symbolic links are an extension, which I believe to be incorrect.<blockquote>Yes, as per my previous note, the final paragraph of the rationale is out of date. It should be disregarded when interpreting the normative text.</blockquote> - It is unclear whether symbolic links in the destination should be followed, and whether the -L and -P options apply, when inspecting destination paths.<blockquote>XBD 4.16 Pathname Resolution requires that symbolic links are followed except when all of the following are true: 1. This is the last pathname component of the pathname. 2. The pathname has no trailing <slash>. 3. The function is required to act on the symbolic link itself, or certain arguments direct that the function act on the symbolic link itself. (Note that "function" here is a reference back to "the function being performed"; it does not mean C language function.) So the only conditions under which cp does not follow a symlink specified as the destination are those where the cp description explicitly says cp acts on the symlink. It says so for -P on line 90628: "shall not follow any symbolic links". I believe all other mentions of acting on the symlink are not related to the destination. (Note that text referring to traversal of the file hierarchy can only be referring to source files, since no traversal is performed for destination files; existence checks are not traversals.)</blockquote> - There is historical precedent for answering these questions with "yes" and "no", respectively. Recent history suggests the wording is vague enough that implementers are confused on the second point.<blockquote>I believe the text in the standard is sufficient to answer the questions. Whether the required behaviour matches what implementations do is another matter. The recent history could be taken as an indication that (at least some) implementors are willing to make changes to conform, once they are made aware of the correct interpretation of the standard.</blockquote> - The description section does not adequately discuss how cp should behave if the source is a directory and the destination exists and is a symbolic link.<blockquote>It needs to be read in combination with XBD 4.16 Pathname Resolution, and noting that -P implies symlinks are not followed for both source and destination.</blockquote> - The description section does not consider the type of the destination at all in the case where the source is a file and the destination exists.<blockquote>Correct, and I don't see any problem with that. If the destination is a directory, the open() call in 3.a.ii will fail and cp will report an error. If -f is specified, an unlink() is attempted in 3.a.iii and will normally also fail, although it does seem to imply that if the implementation supports privileged unlinking of directories then cp will do so when run with appropriate privilege. We should perhaps consider changing the unlink() to remove().</blockquote> Issue History Date Modified Username Field Change ====================================================================== 2024-04-01 15:31 dag-erling New Issue 2024-04-01 15:31 dag-erling Name => Dag-Erling Smørgrav 2024-04-01 15:31 dag-erling Section => Utilities 2024-04-01 15:31 dag-erling Page Number => 2741-2748 2024-04-01 15:31 dag-erling Line Number => 90593-90715, 90876-90880 2024-04-02 06:19 dannyniu Note Added: 0006731 2024-04-02 06:20 dannyniu Note Added: 0006732 2024-04-02 06:21 dannyniu Note Deleted: 0006732 2024-04-02 06:22 dannyniu Note Edited: 0006731 2024-04-02 15:51 geoffclare Note Added: 0006734 2024-04-04 14:30 geoffclare Note Added: 0006737 ======================================================================
