On Wed, 13 Dec 2023, Miklos Szeredi wrote: > On Tue, 12 Dec 2023 at 17:08, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > In short, STATX_ATTR_INUM_NOT_UNIQUE is required to tell userspace when > > they _must_ do the new thing if they care about correctness; it provides > > a way to tell userspace what guarantees we're able to provide. > > That flag would not help with improving userspace software. Are you sure? Suppose I wanted to export an filesystem using some protocol (maybe one called "NFSv4"), and suppose this protocol supported the communication of an attribute called "fileid" which was optional but requires to be fully unique if provided at all. If I had access to STATX_ATTR_INUM_NOT_UNIQUE, then I could not export the fileid when it didn't met the protocol requirements, but could when it did. This may not be a strong case for the inclusion of the flag it is, I think, a clear indication that "would not help" is what our fact checkers would call "over-reach". NeilBrown > > What would help, if said software started using a unique identifier. > We already seem to have a unique ID in the form of file handles, > though some exotic filesystems might allow more than one fh to refer > to the same inode, so this still needs some looking into. > > The big problem is that we can't do a lot about existing software, and > must keep trying to keep st_ino unique for the foreseeable future. > > Thanks, > Miklos >
