On 22/06/16 23:53, Bernhard Voelker wrote: > On 06/22/2016 03:01 PM, Pádraig Brady wrote: >> It'll need this on top, to better differentiate FTS_ERR and FTS_DNR, >> as fts_build may be called multiple times for the same dir. > > Hmm, but rm(1) won't show the errno.
Right, as FTS_DNR is actually passed out as intended in my patch, and rm will try to rmdir() in that case. I did consider the more aggressive FTS_ERR + FTS_STOP, though that would then happen when readdir() returned nothing (with errno). I was worried that some file systems may return NULL + ENOENT for empty dirs for example, which would now cause rm to start erroring where it might not have before. > I'm getting better results with the attached, i.e., handling the > readdir() failure like the other failures way down and setting the > FTS_STOP flag. Another reason I thought FTS_STOP too aggressive was it was currently used only for internal errors where we it didn't make any sense to proceed. > > With Peter's LD_PRELOAD lib, I'm getting this: > > $ LD_PRELOAD=/tmp/libfake_readdir.so ~/findutils/find/find /tmp/ddd > /tmp/ddd > Forcing failure of readdir > /home/berny/findutils/find/find: failed to read file names from \ > file system at or below ‘/tmp/ddd’: Too many levels of symbolic links > > $ LD_PRELOAD=/tmp/libfake_readdir.so ~/coreutils/src/rm -rfv /tmp/ddd > Forcing failure of readdir > Forcing failure of readdir > /home/berny/coreutils/src/rm: fts_read failed: Too many levels of \ > symbolic links > > WDYT? I'd modified the LD_PRELOAD code to have 2 paths. 1. to return NULL immediately and thus return FTS_DNR 2. to return NULL after a couple of iterations and thus return FTS_ERR. If you've objections to my assumptions I'm happy to adjust. Pádraig
