Mikulas Patocka <[EMAIL PROTECTED]> writes: >> Mikulas Patocka <[EMAIL PROTECTED]> writes: >> >>> If POSIX specifies something that is unimplementable (unique stable >>> inode numbers) the question is why to rely on it? >> >> But it's easily implementable, if your file system was written with >> POSIX in mind. > > And if someone else designed it --- like FAT or SMB?
Then it might not be so easy, of course. But going back to your original point: what I was objecting to was the claim that "POSIX specifies something that is unimplementable". Obviously stable file serial numbers are implementable. They just aren't easily implementable if one chooses the wrong implementation strategy. >> In many cases the POSIX folks had to decide whether to make >> concessions to non-Unix practice. For example, should POSIX allow a >> distinction between text and binary files, which is pretty much a >> requirement for DOS-ish file systems? > > This is not filesystem issue, DOS can work with files with '\n' > newlines too. It may not be a file system issue, but it is a DOS issue. And there are similar issues that are file system issues. For example, whether file names are case sensitive. POSIX requires that they must be; many non-POSIX file systems say they are not. >> There are a lot of packages that will break (sometimes subtly) on file >> systems that lack stable file serial numbers > > So tell users not to do it. How should they otherwise find? You can't seriously expect all these applications to change their documentation to say "watch out; this may not work with nonstandard file systems"! That would be sort of like saying "watch out! this won't work if your computer is not plugged in." Generally speaking, warnings about problems with nonstandard file systems belong with the file systems, not with applications. > The most scary thing is that these filesystems most-time work and > break randomly, when inode numbers colide. Yes, that's true. And I wouldn't recommend using these file systems for heavy-duty use in POSIX environments where reliability is important. Their nonstandard behavior breaks too many things. I guess they are OK for less-important duty, since people use them. But we cannot wave a magic wand and declare them reliable and standard; clearly they're not. > Would you really dare to accept a patch that prints > "cp: error, your filesystem is not posix compliant, to prevent > possible data damage, coreutils refuses to operate on it?" That's up to Jim, but such behavior doesn't sound all that useful to me. For light duty applications like "cp foo bar", "cp" should work just fine. Also, it'd be a pain to maintain the list of nonstandard file systems. People are always coming up with new ones. If you can think of a way for "cp" to detect the problem cheaply, at run time, then it would probably be worth putting in a warning. Ideally this would involve no new system calls. For example, if "cp" discovers two files with different types (e.g., one a directory and one a regular file) but the same file serial number, then that would be an indication of the bug. I'm waving my hands a bit here, but I hope you get the idea. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
