| 1 | | `Paul Eggert` seems to have the solution: https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00085.html. I fail to understand… |
| 2 | | |
| 3 | | The `C test programme` is: |
| 4 | | |
| 5 | | {{{ |
| 6 | | 1 if (1) |
| 7 | | 2 { |
| 8 | | 3 static char const dir_name[] = "confdir-14B---"; |
| 9 | | 4 size_t desired_depth = ((TARGET_LEN - 1 - initial_cwd_len) |
| 10 | | 5 / sizeof dir_name); |
| 11 | | 6 size_t d; |
| 12 | | 7 for (d = 0; d < desired_depth; d++) |
| 13 | | 8 { |
| 14 | | 9 if (mkdir (dir_name, S_IRWXU) < 0 || chdir (dir_name) < 0) |
| 15 | | 10 { |
| 16 | | 11 if (! (errno == ERANGE || errno == ENAMETOOLONG |
| 17 | | 12 || errno == ENOENT)) |
| 18 | | 13 fail = 3; /* Unable to construct deep hierarchy. */ |
| 19 | | 14 break; |
| 20 | | 15 } |
| 21 | | 16 } /* end of for loop */ |
| 22 | | 17 |
| 23 | | 18 /* If libc has the bug in question, this invocation of getcwd |
| 24 | | 19 results in a failed assertion. */ |
| 25 | | 20 cwd = getcwd (NULL, 0); |
| 26 | | 21 if (cwd == NULL) |
| 27 | | 22 fail = 4; /* getcwd didn't assert, but it failed for a long name |
| 28 | | 23 where the answer could have been learned. */ |
| 29 | | 24 free (cwd); |
| 30 | | 25 |
| 31 | | 26 /* Call rmdir first, in case the above chdir failed. */ |
| 32 | | 27 rmdir (dir_name); |
| 33 | | 28 while (0 < d--) |
| 34 | | 29 { |
| 35 | | 30 if (chdir ("..") < 0) |
| 36 | | 31 { |
| 37 | | 32 fail = 5; |
| 38 | | 33 break; |
| 39 | | 34 } |
| 40 | | 35 rmdir (dir_name); |
| 41 | | 36 } /* end of while loop */ |
| 42 | | 37 } |
| 43 | | }}} |
| 44 | | |
| 45 | | On line #9 it first creates the subdirectory and, when successful, changes into it. If it had no success it breaks out of the for loop. |
| 46 | | |
| 47 | | On line #20 a pointer to the pathname of the last directory created is stored in array cwd. If pathname could not be determined, the NULL pointer is returned. This is tested in the next two lines and the storage for pathname gets cleared (free'd), line #24. |
| 48 | | |
| 49 | | On line #27 a possibly not existing sub-directory ("confdir-14B---") is removed. Can this work? Does it provoke the report "…: No space left on device"? |
| 50 | | |
| 51 | | On line #28 starts a while loop in which the current working directory is changed to the parent directory ("..") and if successful the now sub-directory "confdir-14B---" is removed (line #35), otherwise an error is raised and the while loop is quit at one (line #30–33). |
| 52 | | |
| 53 | | Is my interpretation correct? Which is the test Paul Eggert sees but not me? |
| 54 | | |
| 55 | | IMO `rmdir()` seems to fail. So why not leaving out (patching away) the line #26–36 and doing the clean-up in two steps (mv branch to X, then rm -rf remaining confdir-14B--- and X) with reliable system utilities? There also seems to be difference in the behaviour of `rmdir()`: Inside the MacPorts environment it tends to fail while in some user's environment it seems to succeed? |
| 56 | | |
| 57 | | I cannot see any reason for a new bug report… |
| | 1 | Was meant for #62994… |
