https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118733
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Enrico Zini from comment #5) > Note that if the file does not exist at the beginning of weakly_canonical, > it does not throw but it's supposed to canonicalize the path according to a > specific algorithm. And it does that. The algorithm assumes a stable filesystem that isn't changing. > It would be useful if the function reverted to that if the file disappears > during its execution. At some point it needs to call canonical on the part of the path that exists. If it stops existing while calling canonical, it's going to report an error. We can handle that error and retry, but the same thing can happen again a potentially unlimited number of times. The function becomes a denial of service if it keeps trying to handle filesystem races indefinitely. > As it is now, for most practical workloads weakly_canonical can only be > called in a wrapper that retries it if it throws. Or call the non-throwing form. The spec is very clear that errors can occur: "path() is returned at the first error occurrence, if any." You should be prepared to handle that. > I appreciate this is formally correct, though frustrately less useful that > it looks on its documentation. The spec tells you that errors can occur. > I would find it useful if the documentation could be updated to document how > the caller would need to take responsibility of handling such type of race > conditions. The same considerations apply for all uses of the std::filesystem library, but there's no universally applicable suggestion for how to handle it.
