File not closed in a TChain

ROOT
1

Hi all, I’m facing this problem:

I have a TChain with a lot of root files and I’d like to know the files that have not been closed properly in order to delete them from the chain.

I tried to use IsZombie() method, but it returns 0 event to a file that has no key (and should be skipped… I guessed 1 for the file corrupted as return value by IsZombie()).

Do you have any suggestion?

Bye…

2

One should first understand why some of your files are not closed.
This should not happen. Please give more details about your script.

Rene

3

[quote=“brun”]One should first understand why some of your files are not closed.
[/quote]
I don’t really know. I’m using files produced by other people. All I know is that when I open one of these files I get the message:

Warning in TFile::Init: file mc.root has no keys

4

Unfortunatly you do not indicate which version of ROOT.
In case you use a version older than 4.02, upgrade your system
to 4.02 or better 4.03 and let me know if you still the problem.
The TChain in the current version can skip corrupted files.

Rene

5

Yep, sorry.
I’m using ROOT 4.01/02

I think I cannot upgrade to a new version due to compatibility with other software :frowning:

I also found this:

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

It seems to almost be my problem: the difference is that I don’t have any keys in the file.

Do you think I can use fNbytesKeys in any useful way?

Thanks
Antonio

6

Have you considered compiling your own private version?

7

For this particular problem, you can test fNkeys (GetNkeys), but the best
is to upgrade your version.

Rene

8

I resolved my particular problem using GetListOfKeys()…

thank you for your support

Bye
Antonio