Thursday, February 28, 2008

Is Unexpected Behavior a Bug?

There's the way you coded it, and the way it should behave. Most of the time, these should be the same. Occasionally, though, this is the kind of thing that causes nightmares. Usually the problems are related to the latter half of that statement - disagreements about the way something should behave.

For example, there is a ... well, we'll say item... introduced in the Linux 2.6.19 kernel. When doing NFS mounts, if you mount a file system first as read-only, all later mounts of the same file system are also mounted read-only. The issue was closed as: "According to the explanation on the upstream bug report, this is a logic change in the way the kernel handles multiple mounts of the same remote nfs file system. Not a bug."

So, is this a bug?
  • Yes. It's a semi-documented (at best) change in behavior that breaks backward compatibility.
  • No. It makes the behavior of mounted remote file systems consistent with the behavior of local file systems.
  • Yes. This has the effect of causing the -rw flag to be useless in some scenarios.
  • No. The flags are requests, not requirements on the file system. Just because you request it, the file system doesn't have to grant you that level of access (for example, you might not have permissions to write to that file system, and no -rw flag will help you there).
I honestly have no position here, but be mindful that when you say something is or is not a bug, you also say what you expect - that way the issue can be resolved, whether it's with code or with expectations.

No comments:

Post a Comment