Dear Paul and Collin, After reviewing the gnulib fts implementation more closely, I agree that using fts_path after an fts_read failure is unsafe. Since its contents are unspecified in this case—potentially NULL or referring to a stale path—including it in diagnostics could lead to misleading messages or crashes.
Based on this, I plan to revise the approach as follows: - Stop using fts_path in fts_read failure paths for chcon, chmod, chown, and rm. - Update du as well, as it currently relies on the same pattern. - Replace the current message with a path-independent diagnostic: "cannot traverse directories". - Update the affected tests accordingly. This ensures the diagnostics remain correct under all failure modes and avoids relying on unspecified state, while maintaining consistent behavior across these utilities. Please let me know if this direction is acceptable. If so, I will prepare and send a v2 with these changes. Regards, Shubham On Sun, 19 Apr, 2026, 3:29 am Paul Eggert, <[email protected]> wrote: > On 2026-04-18 14:22, Shubham Chakraborty wrote: > > I suggest tracking the last successfully > > visited path to provide context when reporting an error. > > Not sure that's a good idea either. The last visited path might not have > nothing to do with the problem. Specific-but-wrong diagnostics are not > generally a win over vague-but-correct diagnostics. > > If this were an easy or shallow problem to fix we would have fixed it > already. >
