Not knowing the details, I'd suggest to implement a generic function to
create an attributed inode and let the fs override it to create an
Benefit: All fs supporting extended attributes will be able to support
whiteout. If the fs has other means of supporting whiteout, they may fake
- Having two ways of reporting a whiteout? Or can it be reported using a
(static) fake inode?
Do a hardlink if you can create a hard link, otherwise use a fresh inode
and use that for the next hardlink(s).
The current version of whiteout support always hides DT_WHT dentries
from userspace. Perhaps a start is to only hide DT_WHT entries when
the file system is union mounted. Applications usually ignore all
dentries with d_ino == 0 so it might not cause problems.
Bleah! Then you have a code path that is only tested when you hit
LINK_MAX. Sounds like a recipe for bugs for me.
You'll also hit it while creating the first whiteout, maybe on creating
the first whiteout since mounting, and on filesystems not supporting
hardlinks (are there some that support attributes but not hardlinks?).
Maybe it will be possible to create immutable whiteout inodes, too.