> On Thu, Jun 4, 2009 at 12:04 PM, Andreas Dilger <adilger@xxxxxxx> wrote: > This sounds very strange - different processes (or even the same > process using different file handles) will see different results > for fstat() which are yet different from stat(). I can't imagine > that applications would like this at all. Ya, no doubt a good deal of applications would get very confused if they didn't know the difference. And it is not the goal of this FS to support the use of general applications. But, because a process has a 'private copy' of the file when it opens it for write-mode (this being an intended feature of this file-system), it's imperative that the application be given the ability to access the data and metadata of the private copy as well as the on-disk version. The on-disk file's metadata would be retrieved via a path-based stat(2) (or by opening another instance of the file read-only and fstat'ing the fd), and the private copy's metadata would be retrieved via fstat(2). > Maybe you should go back and explain why this behaviour is useful, > before we burden the kernel with it. Hardly a burden. It's an interface addition that is completely optional to each filesystem. In Miklos' patch, if the fgetattr method is not set in the file_operations struct, then the behavior is to fallback to the original getattr function. Cheers, - Brian -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
