On Mon, Dec 11, 2023 at 12:04:58PM -0800, Darrick J. Wong wrote: > > Otherwise I'm still a bit worried about the symlink pointing to ? > > and suspect we need a clear and documented strategy for things that > > can change data for applications before doing something like that. > > For a brief second I thought about adding another ZAPPED health flag, > like I just did for the data/attr forks. Then I realized that for > symbolic link targets this doesn't make sense because we've lost the > target data so there's no extended recovery that can be applied. > > Unfortunately this leaves me stuck because targets are arbitrary null > terminated strings, so there's no bulletproof way to communicate "target > has been lost, do not try to follow this path" without risking that the > same directory actually contains a file with that name. > > At this point, we can't even iget the dead symlink to find the parent > pointers so we can delete the inode from the directory tree, so that's > also not an option. Can't we have a zapped flag that: a) let's it pass the verifier b) but returns -EIO on any non-scrub access?
