No need for virtual experiments, ok, for this, but may be for some nice old computer games ... I got the restore managed. Paragon's newest version is not able to read their old stuff directly cause they have changed something for better whatever. But in the outlast corner there are 3 points ... and clicking on that they offer to work with "old PBF files". That someone should know and find ... though for all endusers to which the community edition is adressed even better cause its a most dangerous function. Choice a PBF and a harddisk with enough room and they write back to stuff ... as first deleting and reformating the HD complete. Was good that I had two empty partitions, one to be rebuild and one to get than manually copied the needed stuff. So I have all got back and rebuild the used partition again to normal state.

Wow, it's interesting and a little sad how much or better less is remaining from more than 25 years of day-by-day hard programming ...

But now I know again why I had stopped working on this theme. I had not unzipped and cataloged the original packages but run over installed content to catalog and find/build relations. So I found dozends of paths e.g. c:programsposer... or d:curioslabs... or e:myposerstuff... in obj-references or texture-references. Ok, a lot of this can be reworked by a intelligent automatic although special in textures these paths are seldom consistent used in one file. But much more worse are duplicate names, e.g. black.jpg. In around 100 test cases I found 14 references to that file. But its not everytime the same file, would be to easy, and therefor this is not solvable by program. If even a user is in doubt what belonges to what then you can not build any algorithem to solve this by program. A problem what even Poser itself has. If you have textures and also objects with identical names it often happens that Poser makes a decision what is not what you expect or want. And this can even happen cross runtimes ... :-(

So that was the point I stopped that project years ago cause I had no (save) ideas how to overcome such problems. Ok, there is a lot a user can estimate and solve but without being involved in the Poser program details there is much, much you can be right or not. And therefor a post a bit back from FVerbaas is absolutely correct ... it is a big project AND the most work will/must be done in maintenance cause that is the time things become clear ... a typical banana software - green on delivery and mature by user input.

So for me working on file internal references makes not much sense cause I have Dimension3D's fantastic runtime organizer and poser editor both doing a superb job. Only to run over complete downloaded packages to catalog what all is living on the harddisk would be a nice thing. Also unpacking I will do by hand cause I do it into a empty work directory and afterwards arrange the stuff into my runtimes depending on my choice and thats seldom identical with what the creator has packed. So for example all those licence and readme files are subject to the rubbish box and all those long pathnames with creators name is wasted space and scheme. Good for the creators absolute no discussion but for the usage of a runtime not very neccessary.