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-06-10 18:16 UTC ====================================================================== Summary: cp: directories and symlinks ======================================================================
---------------------------------------------------------------------- (0006807) eblake (manager) - 2024-06-10 18:16 https://austingroupbugs.net/view.php?id=1824#c6807 ---------------------------------------------------------------------- A lot of this stems from Linux's intentional decision years ago that when readlink("dangling") returns "newdir" but stat("dangling") fails with ENOENT, then rename("olddir", "dangling/") should fail with ENOTDIR, instead of leaving "dangling" intact as a symlink and renaming "olddir" to "newdir". It is not just rename() affected; mkdir(), unlink(), and several other Linux syscalls intentionally refuse to dereference through a symlink followed by a trailing slash on the grounds that it is somewhat ambiguous on whether you wanted to act on a (potential) directory name or on the symlink itself. Is it time to recognize the Linux syscall behaviors on dangling symlinks as a valid alternative to traditional Unix behavior (a much bigger change to identify all of those affected interfaces, but would make it easier for Linux to finally comply with POSIX), or are we only wanting to paper over this scenario at the command line interface of cp despite Linux being unwilling to change kernel behavior at the C level, or something else altogether? 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 2024-04-04 16:01 dag-erling Note Added: 0006739 2024-04-04 16:59 geoffclare Note Added: 0006740 2024-04-04 18:19 geoffclare Note Edited: 0006740 2024-04-05 08:16 geoffclare Note Edited: 0006740 2024-04-05 11:33 dag-erling Note Added: 0006741 2024-04-08 08:39 geoffclare Note Added: 0006743 2024-04-08 08:42 geoffclare Note Edited: 0006737 2024-04-08 08:44 geoffclare Note Edited: 0006743 2024-05-20 09:26 geoffclare Note Added: 0006788 2024-05-20 09:28 geoffclare Note Edited: 0006788 2024-06-10 18:16 eblake Note Added: 0006807 ======================================================================
