I have observed that hadd in some cases produces broken output files. From what I could see so far, this seems to happen whenever one is using it in a trivial case (just one input file), and the file contains TTree objects. If such a damaged output file is opened in a TBrowser and one attempts to draw the contents of any branch, one is greeted with a multitude of error messages like the following:
Error in TFile::ReadBuffer: error reading all requested bytes from file out_PeriodB2_TOPEL_Egamma_1jet_pretag.root, got 0 of 146
If such a file is then used in subsequent hadd commands, the resulting file is also damaged. For me this happens frequently, since I split my jobs into several files per period that need to be merged, and later on I usually also merge results for a set of periods.
I would guess that this case is very easy to catch in hadd.
thanks for your reply. The problem did indeed disappear in 5.32. I was using 5.30/00 before (sourced from /afs/cern.ch/sw/lcg/app/releases/ROOT/5.30.00/i686-slc5-gcc43-opt/root).
It’s probably no longer relevant, but if you want to reproduce it, here is a minimal example (just creating a TTree with one branch):
{
int RunNumber;
TFile* f = new TFile("tree.root", "RECREATE");
TTree* t = new TTree("simpletree", "Simple Tree");
TBranch* b = t->Branch("RunNumber", &RunNumber, "RunNumber/I");
for (int i = 1; i < 10000; ++i) {
RunNumber = i;
t->Fill();
}
f->Write();
f->Close();
}
Then hadd sum.root tree.root and open the files in a TBrowser. I observed that tree.root is filled as expected, but sum.root is damaged.