> > This change has the side-effect of removing the capability of the root > directory from being case-insensitive. It is not a backward > incompatible change because there is no way to make the root directory > CI at the moment (it is never empty). But this restriction seems > artificial. Is there a real reason to prevent the root inode from being > case-insensitive? > I don't have a use case where I need a root directory to be CI. In > fact, when I first implemented CI, I did want to block the root directory > from being made CI, just to prevent people from doing "chattr +F /" and > complaining afterwards when /usr/lib breaks. > > My concern with the curent patch was whether this side-effect was > considered, but I'm happy with either semantics. > > -- > Gabriel Krisman Bertazi That's just from the lost+found directory right? If you remove it you can still change it, and then add the lost+found directory back. Isn't that how it works currently? I definitely didn't intend to change any behavior around non-encrypted casefolding there. I should look at what fsck does if you do that and have a LoSt+fOuNd folder... -Daniel Rosenberg
