On 3/26/22 18:54, Kyle Glaws wrote:
When the shared library is missing, execvp will set errno to ENOENT. In
that event, it might be possible to stat the path to the command to confirm
that the command does not exist.
That would lead to a race condition, in case the file in question is
removed
Here are the last few lines in chroot.c::main for reference:
...
/* Execute the given command. */
execvp (argv[0], argv);
int exit_status = errno == ENOENT ? EXIT_ENOENT : EXIT_CANNOT_INVOKE;
error (0, errno, _("failed to run command %s"), quote (argv[0]));
return exit_status;
}
When
On 3/26/22 16:16, Kyle Glaws wrote:
Looking at the source code in chroot.c, it doesn't seem impossible to add
some logic that makes this error message more accurate (i.e. that a shared
library is missing, not the executable itself).
How? More details, please.
Hello,
I have encountered an issue with chroot (from Coreutils version 9.0), but I
think this email might fall more under the category of "comment" or maybe
"question" rather than "bug report", since it's not clear that the observed
behavior is unintentional.
I have noticed that chroot will incorr
The dd Texinfo doc says, for the conv= option
(https://gnu.org/s/coreutils/manual/html_node/dd-invocation.html)
'fdatasync'
Synchronize output data just before finishing. This forces a
physical write of output data.
'fsync'
Synchronize output data and meta
