Hi Sue,
Thanks for reporting this use case and the corresponding code.
Now in CVS.
Rene Brun
:wq
On Sun, 10 Feb 2002, Susan Kasahara wrote:
> Hi Rene,
> Thanks for the fix and I have tested it and find that it works. I'd
> like to request one more change please to accomodate another
> use case for this particular situation in which the file has been
> opened by the writer but no keys have been written to the file. This additional
> use case is that we have a daq -> dispatcher configuration running at our
> detector site in which a dispatcher serves data from the data file while the daq
> is still writing to it. To support this, the daq writer uses TDirectory::SaveSelf, and
> the dispatcher reader uses TDirectory::ReadKeys as is described under
> TDirectory::ReadKeys. This works well as long as at least 1 key has been
> written to the file by the daq writer.
> In the case described below, in which the file has been opened by the
> writer, but no key has yet been written to the file, I would like to be able to open
> the file with no error message reported, and have TDirectory::ReadKeys
> return the number of keys = 0. This would allow me to treat this particular
> case the same as if one or more keys have been written to the file.
> I have played with implementing this in my own TFile.cxx and TDirectory.cxx
> and have attached what I have done. It works for my tests, although I am sure
> I have not done implemented it carefully enough. It is just to give you an idea
> of the behavior I'm hoping for.
> -Sue
>
> In TFile::Init change:
>
> //*-* -------------Read keys of the top directory
> if (fSeekKeys > fBEGIN && fEND <= size) {
> TDirectory::ReadKeys();
> gDirectory = this;
> } else {
> if (fEND > size) {
> Error("TFile","file %s is truncated at %d bytes: should be %d, tryi\ng to recover",GetName(),size,fEND);
> } else {
> Warning("TFile","file %s probably not closed, trying to recover",Ge\tName());
> }
> if (!Recover()) goto zombie;
> }
>
> to:
>
> //*-* -------------Read keys of the top directory
> if ( fEND <= size) {
> TDirectory::ReadKeys();
> gDirectory = this;
> } else {
> Error("TFile","file %s is truncated at %d bytes: should be %d, tryi\ng to recover",GetName(),size,fEND);
> if (!Recover()) goto zombie;
> }
>
> In TDirectory::ReadKeys change:
>
> TKey *headerkey = new TKey(fSeekKeys,fNbytesKeys);
> headerkey->ReadFile();
> buffer = headerkey->GetBuffer();
> headerkey->ReadBuffer(buffer);
> Int_t nkeys;
> TKey *key;
> frombuf(buffer, &nkeys);
> for (Int_t i = 0; i < nkeys; i++) {
> key = new TKey();
> key->ReadBuffer(buffer);
> fKeys->Add(key);
> }
> delete headerkey;
>
> to:
>
> Int_t nkeys = 0;
> if ( fSeekKeys > 0) {
> TKey *headerkey = new TKey(fSeekKeys,fNbytesKeys);
> headerkey->ReadFile();
> buffer = headerkey->GetBuffer();
> headerkey->ReadBuffer(buffer);
> TKey *key;
> frombuf(buffer, &nkeys);
> for (Int_t i = 0; i < nkeys; i++) {
> key = new TKey();
> key->ReadBuffer(buffer);
> fKeys->Add(key);
> }
> delete headerkey;
> }
>
>
> Rene Brun wrote:
>
> > Hi Sue,
> >
> > I have modified TFile::Recover such that the file is declared a Zombie
> > if no keys can be recovered. Fix in CVS.
> >
> > Rene Brun
> >
> > Susan Kasahara wrote:
> > >
> > > Hi root team,
> > > Sometimes we need to read a file that was left open by an aborted write job. In this
> > > case the file is not properly closed, and on read of the file the TFile::Recover method
> > > will attempt to rebuild the key directory for the file. If the TFile::Recover method
> > > fails to recover any keys for the file it prints the warning message: "no keys recovered"
> > > for the file, but I can't seem to find a way to determine at run time that in this case the
> > > file is unreadable. The TFile methods IsZombie() and IsOpen() both indicate after
> > > TFile construction that the file is open and ready to be read. This causes my code
> > > to go ahead and attempt to read the set of keys from the file (TDirectory::ReadKeys
> > > returns a non-null number of keys) and use the keys, eventually resulting in a segv.
> > > Is it possible to determine at run-time that the file was not recoverable?
> > > I am using cvs root last updated on 1/22/02.
> > > -Sue
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:41 MET