hadd with -n option misses some content

[will-cern]

I haven't had a chance to look into the hadd code (TFileMerger) but in 6.24/04 I the following problem. Create two files like this:

{
  TFile f1("f1.root","RECREATE");
  TH1D h("h1","h1",10,0,10);
  h.Write();
  f1.Close();
  TFile f2("f2.root","RECREATE");
  TH1D h2("h2","h2",10,0,10);
  h2.Write();
  f2.Close();
}

now if we hadd these as normal (hadd merge.root f1.root f2.root) we get both histograms:

TFile**         merge.root      
 TFile*         merge.root      
  KEY: TH1D     h1;1    h1
  KEY: TH1D     h2;1    h2

but do this with the -n 1 option I only get h1:

TFile**         merge.root      
 TFile*         merge.root      
  KEY: TH1D     h1;1    h1

[jblomer]

Additional observation: -n1 is different from -n 1. I can reproduce the problem with -n 1 on master.

[jblomer]

Option parsing in hadd demands a space between -n and the value. The value is passed on to TFileMerger::SetMaxOpenedFiles() which in turn sets it to a minimum value of fMaxOpenedFiles = 2.

From my tests, it appears that TFileMerger merges the first fMaxOpenedFiles - 1 input files, which is probably not the desired behavior.

[jblomer]

I'm reassigning to Philippe. I think it boils down to this: when processing the excess files, TFileMerger switches to the incremental mode. In this mode, TFileMerger::MergeOne sets canBeFound = true, which in turn at the end of MergeOne skips the if block commented with // Don't write the partial result for TTree and TH1. Perhaps canBeFound should not be true for a histogram that is not (yet) found in the target file?

[pcanal]

@silverweed Can you check this issue?