I have some old root files created with ROOT 4.04/02 that use the “CS” compression (fCompress==1). My goal is to convert them to a newer compression so they can be read with uproot4 as input to some existing statistical analysis.
I’ve found I’m able to create a new file with more modern compression via the rootmv command. rootmv -c 5 ./old_compression.root ./new_compression.root
However, this also has the undesirable side effect of merging trees ex. TreeA;14 , TreeA;13 become TreeA;1 in the new file.
However, this change to the compression doesn’t seem to extend to all objects in the file.
I’m wondering if there is a better way to update the compression, and if it is possible to avoid merging trees like this in the process and if it is possible to do this recursively for all object in the file.
Do you really have a non-standard use for cycles? In most use case the lower cycle number are just a backup copy of the TTree meta and ‘TTreeA;14’ point to all the entries pointed to by `TTreeA;13’ plus all the entries added after the ‘13th’ snapshot. Usually the lower cycles are only useful for recovery from a crash in the file writer. I.e. in the standard use, you lose nothing by no having access to the older cycles (but same some space).
All the automatic tools are assuming this usage and thus discard the older cycles, to keep the cycle you will need to code the copy explicitly.
I haven’t found an explicitly non-standard use of cycles with root files in the codebase that produces these.
I’m a little concerned about it because the processing pipeline that produces them uses a lot of hbook files, and I have seen input of hbook files that references both the first and last cycles. This usage may not exist for root files though, and so this could turn out to be a non-issue in the end.
Unfortunately it seems the rootmv procedure I was using earlier doesn’t actually change the compression for all objects in the file. So the question remains if there is a more robust way to do this.