Miklos Szeredi <[EMAIL PROTECTED]> writes: > If you were thinking of a soltuion, where the filesystem itself > supplies two different inode numbers based on the variant of the > userspace interface, then I'm sorry to inform you, that this sort of > interface is not likely to happen in the Linux kernel.
I don't see why not. Why can't the file system tell what system call was used (the legacy smallfile one or the largefile one)? Surely there is some way to find out, even if it's not as convenient as we'd like. And if there's no such way, then add one. If it's too much trouble to implement this, then just issue 32-bit hashes. That's not perfect, but it'll be good enough for most casual uses. Or have it be a mount-time option whether to use 32-bit hashes (to support smallfile legacy apps, albeit with some collisions possible) or 64-bit hashes (to support modern apps, with little possibility of collision). There are lots of ways to go here, without having to port standard utilities to substandard file systems (which has the side effect of dumbing the utilities down and making them less secure). > If you were thinking of automatically converting a 64bit inode number > to a 32bit one (e.g. truncating it) Yes, I was thinking of the _filesystem_ doing that. Not glibc. Not the kernel. The _filesystem_. It's the filesystem's responsibility to know that its inode numbers are somewhat bogus; the kernel and/or glibc can't be expected to know that on their own. > However, I realized that inode numbers generated by hashing the path > have another fatal problem. Namly that if you rename a file or > directory, then the inode number will of course move with the name, I was relying on your earlier statement that a file was uniquely identified by its path, and that therefore a rename results in a different file. Those semantics are not great, but they're better than nothing. There must already be such problems with hard links anyway, so this extra problem isn't that much worse. >> Sure it is. All it takes is sufficient resources. You could maintain >> an auxiliary inode table outside the file system, for example. > > And this could be an ever growing table, as the filesystem may not be > aware of any removals on the server end. That's not a problem. If the table has garbage and gets too large then the file system can garbage-collect it. I don't seriously expect you to rush out and implement the inode table right away. All I'm trying to show is that it's indeed possible to implement POSIX semantics, so that the claim that "it is _NOT_POSSIBLE_ to make these filesystems conform to POSIX" is incorrect. With an auxiliary table, one can even implement POSIX-style renames and hard-links. The issue is not whether it is _possible_ to conform to POSIX; it clearly is. The issue is to find a reasonable design point where the most commonly-run applications work and where it doesn't cost too much to implement it. Again, it is unreasonable to expect standard utilities to port around file systems that don't have reliable inode numbers. It breaks too many other things: simplicity and security being the most important two. People will just have to learn to not trust running standard utilities on file systems that lack reliable-enough inode numbers. _______________________________________________ Bug-findutils mailing list Bug-findutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-findutils
