I’m having issues with ROOT creating a new TFile when a TTree grows beyond fbMaxTreeSize. The problem stems from the fact that the TFile pointer may or may not change, and there doesn’t seem to be any way to notify external objects that such a change has happened. The docs say to always check TTree::getCurrentFile(), but if one has an external structure that contains the opened TFile pointers, this doesn’t help much - have to loop over all TTrees that are being managed (this is for the Gaudi THistSvc), see if the TFile ptr is the same as what it was originally opened with, and if not, figure out what to change it to (I need to keep track of the TFiles in order to write them out properly at the end of the job). However, sometimes even when the file has changed names, the TFile ptr has not changed values, so what I really need to do is to monitor all the file names! This is not good.
Is there any way to get a callback when the TFile closes, and a new one is opened?
You have a few options. You could disable this mechanism altogether by calling TTree::SetMaxTreeSize with a very large number (and implement your own file switcher if needed). You could keep the address of the TTree in lieu of the TFile and always call GetCurrentFile to access the TFile.
Finally the one call back you can get is to be warned when the TFile is deleted (but you are not told by what it is replaced). If you register an object inheriting from TObject to gROOT->GetListOfCleanups() then each time an object is delete that object’s RecursiveRemove function will be called with the address of the deleted object as a pointer.
I just tried your last suggestion of registering an object with gROOT->GetListOfCleanups() , but it doesn’t seem to detect the deletion of the TFile when the file changes. In fact, it doesn’t even detect it when I do an explicit delete of the TFile ptr. It does notice the deletion of the TTree in the TFile though.
Yah, I saw that. But that’s not the concern - in fact, if I could avoid splitting the files, that would be the best, but it seems that some users want to do that. Hmmm, maybe I’ll just make it a policy that no files can be split. However, this may become a problem if the files grow beyond 4GB.