Good idea 
Let me know if I can be of any help with the “segmentation violation”.
[quote]I’m not sure if this is what you want … if not, let me know your preferred command …
(and for the moment, my ROOT is not compiled with the “debug” option)[/quote]This was indeed what I was looking for. Unfortunately, it indicates that something went wrong:root [3] gROOT->GetRootFolder()->FindFullPathName("shDsssdE")
==12950== Invalid read of size 1
==12950== at 0x4026038: strlen (mc_replace_strmem.c:282)
==12950== by 0x48F3C96: G__valuemonitor(G__value, G__FastAllocString&) (in /.../v5-28-00-patches/lib/libCint.so.5.28)
....
==12950== Address 0xd612a380 is not stack'd, malloc'd or (recently) free'd
but not what … I still can not reproduce it at all, so I suspect that it might be a build problem (i.e. maybe you could try to rebuild your ROOT version from scratch). In addition, if you can reproduce it with a debug build, we could use gdb to try to figure out what happens in your case.
Cheers,
Philippe.
I always build ROOT from scratch (destroying the “old” version in advance). 
I will rebuild my ROOT tomorrow with “–build=debug”. I’ll let you know the result here.
Hi,
I finally found the problem and resolved it in the trunk (revision 38685) and v5-28 patch branch. It was a case of mistaken identity where the mistaken and the mistakee where looking close enough alike that the problem only appeared ‘sometimes’ and only in optimized builds …
Cheers,
Philippe
VIVE L’AMOUR!
great job
(ROOT 5.28/00b, svn revision 38685 … works now without “segmentation violation”.)
However, I think I would like to propose yet another change to the “FindFullPathName” behavior.
- If one calls it from “gROOT->GetRootFolder()”, it can return the full absolute path starting with “//root” (or maybe even better the relative path without the leading “//root/”, for a strict consistency with the point 2. below - this should not make any problems for the “gROOT->FindObject” call at all, I believe).
- if one calls it from a “my_folder”, it should return the path fully relative to this folder WITHOUT the leading “/my_folder/” string.
The reason for the point 2 is the following:
root [2] gROOT->GetRootFolder()->Add(histos)
root [3] gROOT->GetRootFolder()->FindFullPathName(“histos”)
(const char* 0xb77ed980)"//root/histos"
So, if the call ‘histos->FindFullPathName(“shDsssdE”)’ returns “/histos/singles/shDsssdE”, then it is difficult to create the “full absolute path” from these two strings (as the “/histos” substring appears in both of them).
Now, if the ‘histos->FindFullPathName(“shDsssdE”)’ returns just “singles/shDsssdE”, then it is easy to add “//root/histos” + “/” + “singles/shDsssdE” (similarly, if the call ‘gROOT->GetRootFolder()->FindFullPathName(“histos”)’ returned just “histos”, without any leading “/” or “//root/”, then “histos” + “/” + “singles/shDsssdE” would also work well and one could even manually add “//root/” in the beginning, if desired).
The additional advantage is that … if I have a fully relative path “singles/shDsssdE”, I can easily find the fully absolute path using just:
root [5] gROOT->GetRootFolder()->FindFullPathName(“singles/shDsssdE”)
(const char* 0xb7804980)"//root/histos/singles/shDsssdE"
And that works no matter if the “histos” is the “top_level_folder” added to the “RootFolder”, or not.
Such a search would not be successful if the path would begin with a “/some_folder” string and this “some_folder” would not be the “top_level_folder” added to the “RootFolder”, as can be seen in this example:
root [6] gROOT->GetRootFolder()->FindFullPathName("/singles/shDsssdE")
(const char* 0x0)""
And finally, this works, too:
root [7] gROOT->FindObject(“histos/singles/shDsssdE”)
(const class TObject*)0x9021400
so the leading “//root/” is not strictly necessary, and hence the call ‘gROOT->GetRootFolder()->FindFullPathName(“shDsssdE”)’ can safely return the fully relative path “histos/singles/shDsssdE”, I believe (which the user can manually prepend with “//root/”, if desired).
I hope I was clear trying to explain it. Well, in order to describe it well, I edited this post at least 20 times up to now (during the last 2 hours from its creation time).
A pitiful case, am I not?
Pepe Le Pew.
Hi,
Fair enough. I updated the code to return a useable (but relative) path when called from a lower level node.
Cheers,
Philippe.
Well, another funny question.
root [0] TFile file = new TFile(“run.root”, “READ”);
root [1] file->GetPath()
(const char 0x9b32f68)"run.root:/"
root [2] gDirectory->GetPath()
(const char* 0x9b32f68)“run.root:/”
Can I somehow combine the string “run.root:/” with “histos/singles/shDsssdE” in order to Get/Find the object?
Something like:
gROOT->FindObject(“run.root:/histos/singles/shDsssdE”)
[quote]Can I somehow combine the string “run.root:/” with “histos/singles/shDsssdE” in order to Get/Find the object?[/quote]No. The TFile/TDirectory and the TFolder universe are completely separate.
Cheers,
Philippe.
But … the description of “TFolder::FindFullPathName” explicitly says … “The returned path will be re-used by the next call to GetPath()” … so I wondered if there was a deeper logic related to both strings (i.e. that I can combine them and get a usable file_absolute path).
(O.K., I’ve forgotten that the “TDirectoryFile” has no “FindFullPathName” method at all.)
Hi,
‘GetPath’ was a typo and was meant to say ‘TFolder::FindFullPathName’ (and the comment point to the odd but efficient implementation of TFolder::FindFullPathName).
Cheers,
Philippe.