From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13274 invoked from network); 23 Jan 2022 15:44:15 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Jan 2022 15:44:15 -0000 Received: (qmail 23831 invoked by uid 550); 23 Jan 2022 15:44:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23797 invoked from network); 23 Jan 2022 15:44:13 -0000 Date: Sun, 23 Jan 2022 16:47:37 +0100 From: Ismael Luceno To: musl@lists.openwall.com Message-ID: References: <20220122145158.3779-1-ismael@iodev.co.uk> <20220122145158.3779-2-ismael@iodev.co.uk> <20220122155057.GA11883@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220122155057.GA11883@voyager> Subject: Re: [musl] [PATCH v2 1/2] nftw: implement FTW_CHDIR On 22/Jan/2022 16:50, Markus Wichmann wrote: > On Sat, Jan 22, 2022 at 03:51:58PM +0100, Ismael Luceno wrote: > > @@ -133,9 +136,16 @@ int nftw(const char *path, int (*fn)(const char *, const struct stat *, int, str > > } > > memcpy(pathbuf, path, l+1); > > > > + if (flags & FTW_CHDIR) > > + orig_dfd = open(".", O_CLOEXEC | O_PATH); > > + > > pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cs); > > r = do_nftw(pathbuf, fn, fd_limit, flags, NULL); > > pthread_setcancelstate(cs, 0); > > + if (flags & FTW_CHDIR) { > > + fchdir(orig_dfd); > > + close(orig_dfd); > > + } > > return r; > > } > > > > -- > > 2.33.0 > > > > Erm... maybe a dumb question, but what if either the open() or the > fchdir() fails? Is anything specified for that case? Is effectively > ignoring FTW_CHDIR OK in that case or would you have to signal failure? > I mean, I see that there is not much you can do in either case, but to > just fail silently seems wrong to me. Ah, indeed. I'll try to address that.