 |
 |
Hi Daniel, Nothing prevents the client from issuing a stat() even on an open file. The only difference is that with stat() the client specified the path while fstat() requires the file handle associated with the open file. Andy On Mon, 23 Oct 2006, Daniel Engh wrote: > ok, I'll play around with it. > > stat() is also used on already-open files. > in my case, xrootd issues stat()s on my data file even tho it is > already open and fstat() has already checked it out. > > In the client I am switching from a simple TFile::Open() to some sort > of streaming option. I assume stat calls will be different > when I change this, maybe the client will stick with fstat. > > Dan > > On Oct 23, 2006, at 4:00 PM, Andrew Hanushevsky wrote: > > > Hi Daniel, > >>> however xrootd uses both fstat() and stat() redundantly or > >>> interchangeable and assumes they are the same. (?? I think, I > >>> don't know) is this correct? I don't understand how or why > >>> xrootd needs to use both fstat and stat to retrieve the same > >>> information -- why isn't the initial fstat operation > >>> sufficient? what more does a subsequent stat operation > >>> provide? why aren't subsequent checks also fstat? > > Yes, stat() and fstat() are assumed to return identical results. > > stat() is used for files that are not currently opened while fstat > > () is used for already opened files. There are many oddities in the > > root framework that cause stat() and fstat() to be issued multiple > > times. While we'd like the client not to do this; there is little > > that can be done without spending a lot of time correcting less > > than optimal code. So, the server simply has to manage misbehaving > > clients. > > > > Andy > >