I have a job which opens a TFile in "UPDATE" mode and tries to write a new TTree to it. The job crashes before TFile::Write is called, so the TTree is not written to the TFile (as evidenced by looking at the output from TFile::ls). However, although the TFile's contents appear to be the same both before and after the job crashes, the TFile's size is much larger after the job crash (the TFile size is increased by over a factor of 2). So, there is definitely something in the TFile that wasn't there before the job crashed. Is this normal behavior for a TTree/TFile after a job crash? If so, is there a way to "defragment" a TFile after a job crash to reduce the TFile back to its original size? Here is the contents of the TFile before AND after running the job that crashes: root [0] TFile f( "tests/testAnalysis.root", "READ" ); root [1] f.ls() TFile** tests/testAnalysis.root TFile* tests/testAnalysis.root KEY: TDirectory year_1993;1 Analyzed WAB for year 1993 KEY: TDirectory year_1994;1 Analyzed WAB for year 1994 KEY: TDirectory year_1995;1 Analyzed WAB for year 1995 KEY: TDirectory year_1996;1 Analyzed WAB for year 1996 KEY: TDirectory year_1997;1 Analyzed WAB for year 1997 Finally, here are the file sizes of the TFile both before and after the job crashes: $ ls -la -rw-r--r-- 1 langston langston 22831040 Oct 9 14:48 testAnalysis_before.root -rw-r--r-- 1 langston langston 49614833 Oct 10 11:53 testAnalysis_after.root Thank you for any assistance you can provide. Regards, Matt -- Matthew D. Langston SLD, Stanford Linear Accelerator Center langston@SLAC.Stanford.EDU
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:35 MET