Paul Eggert wrote:
> > How about module 'fts'? Should the directory fds that it allocates also be
> > made O_CLOEXEC?
>
> Yes, I'd say so; I see little reason for a child process to continue an fts
> scan.
Done through this patch. In fact, you had already done most of the work
on 2017-08-12.
Br
On 5/27/20 11:43 AM, Bruno Haible wrote:
> How about module 'fts'? Should the directory fds that it allocates also be
> made O_CLOEXEC?
Yes, I'd say so; I see little reason for a child process to continue an fts
scan.
On Wed, May 27, 2020, 11:44 Bruno Haible wrote:
> The gnulib module 'open' supports O_CLOEXEC since 2017-08-14. We can use it
> to make multithreaded application that call fork() and exec() more robust.
>
> Here are proposed patches.
>
> How about module 'fts'? Should the directory fds that it al
On 2020-05-27 20:43, Bruno Haible wrote:
> How about module 'fts'? Should the directory fds that it allocates also be
> made O_CLOEXEC?
+1
I doubt that passing on those fds to any child is wanted/necessary.
At least that would be a bug for coreutils (rm,du,chmod,chgrp,chcon)
and findutils (find).
The gnulib module 'open' supports O_CLOEXEC since 2017-08-14. We can use it
to make multithreaded application that call fork() and exec() more robust.
Here are proposed patches.
How about module 'fts'? Should the directory fds that it allocates also be
made O_CLOEXEC?
2020-05-27 Bruno Haible
