Mikulas Patocka <address@hidden> writes:
Mikulas Patocka <address@hidden> 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.
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.