Old DSON and file locating system question for DAZ Devs
EvieS
Posts: 62
I've read through several archived discussions regarding DSON but I have a question that I feel only DAZ developers can answer correctly and since the answers will be very pertinent to a lot of other users, I wanted to post it here in hopes of a public response.
POINT:
I use Poser but this is a Studio/DSON issue. I have been using (like many others) Studio and DSON to auto-fit clothing and props to transfer to Poser for use there. I have had no problems with this. Works great. Been doing it for years in fact.
PROBLEM:
I recently discovered DSON is replicating Cr2's, OBJ, and PMD files into a secondary Poser Runtime that I have (I use multiple Runtime directories aside from the main program one to prevent pollution of my program directory --- so in case I have to reinstall I don't lose or corrupt my Runtime directory). So I'm comparing this file directory located here: ("my personal runtime directory name" : RUNTIME / DSON / auto-adapted ) to the place where I usually save files (another Poser Runtime) and have found completely redundantly named files that I didn't make and should not be here.
DETAILS:
When I convert a clothing item (example) in Studio to use in Poser, I have to go through the whole nine-yards of having Studio create a supporting Cr2 for the saved DUF file. These files are all in my Studio runtime (or at least I thought). Now when I tire of the converted file and decide to delete it, or I resave it, or whatever - only the primary Studio/Poser files are being deleted. These things duplicated over in the auto_adapted directory remain in random "gobbly nonsense" named files that can't be matched to the original files. It's hogging up (currently) some 50+ GB on my limited HD. I'm afraid to delete them wholesale because I don't know if they are necessary for existing figures I've got saved. I've noted some of the texts for my Poser saved versions of DSON related files contain OBJ paths going to this auto_adapted directory. So I'm betting deletion would destroy my saved files in Poser (aka, they would not reopen) if I delete them.
QUESTIONS:
- Why is DSON doing this?
- Can these files be deleted?
- Why aren't they deleted when I delete the original files via Studio or Poser delete functions?
- What is the purpose of these random (and duplicant) files?
- Who's bright idea was it to randomly chock these files in random-named files that can't be sorted? (Probably won't get an answer on that one, but it's a pertinent point that needed to be made I think as it relates a failure of logical design and data flow as well as traceable archiving - all things important for program functionality.)
And before anyone is so bold to point it out --- Yes, I am aware DSON is no longer being supported and Poser doesn't work with it (v12+) --- but many of us are still using older versions so it's still a very relevant set of questions that deserve answers.
Anyway, here's hoping for some answers. If you are NOT a DAZ developer or tech support, please refrain from chiming in. I know it's a public forum but if you didn't work on Studio or DSON, you're not knowledgeable enough to address this with surety and failure in that could result in people being misinformed over whether these files can be safely deleted. So please don't state something you aren't qualified to state. You could easily cause someone to delete an unrecoverable file or to retain unnecessary junk on their computer. Answers on this will be very important, so please don't jump in unless DAZ signs your paychecks. Thanks in advance and apologies for being blunt about potential responses. I just don't want my post to start chaos or to end up misleading someone into losing files they need.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
DSON is a file format - you are talking about the tools for exporting Poser comapnion Files for use with the DSON Importer, which allows some DSON-format files to be brought into Poser. I am not sure those files are needed at all, in that they can be rebuilt ("Auto_adapted") on loading the content again - at least for direct imports. Try renaming the folder and then loading both soem of the exported content and some scenes using exported content, if they fail you can always roll back the change.
You could check the more-existant-than-some-believed-documentation http://docs.daz3d.com/doku.php/public/software/dson_importer/poser/referenceguide/tech_articles/a_deeper_look/start - especially the penultimate paragraph.
Excellent test idea, Richard - but by this point I'm not even sure what these files connect to. They have no names. Many are just random like "XWIODKWEI348402?JDKSOOE" -- sort of garbage. I've previously read through the DSON documentation which is why I was worried. This tidbit in particular is troubling:
What exactly does this mean? You have to have a Poser Runtime writeable for it to save the Cr2 file that Studio creates. Sure. We get that. I understand that. Then when I open Poser - there's my newly converted DSON file. I click it to load and it should refer back to data in the original DUF file via the Cr2 companion. It does and it works great. If I save my file in Poser (after loading and posing or whatever) my Poser creates a new Cr2 and a PMD (for morphs) and will generate an OBJ base and MTL for it. It will still use DSON to load because some elements of the file are still exclusively Studio file type (I assume). So where in this process does the material in the [AUTO_ADAPTED] file come into play? Why are they there? Poser didn't make them yet they are in my Poser runtime directory. DAZ didn't need them (that I can fathom) - so what gives? Or is DSON disrupting my Poser save option and hijacking it? I've opened a few of my Poser made Cr2's in text editor and found that the OBJ files are referring to this auto-adapted location rather than Poser's geometry file. That's a hijacking of Poser's save feature. Poser saves geometry files to the geometry index...not off in random locations. Poser is nice and tidy about things like that. So I'm pretty sure deleting of things in that auto_adapted file would crash and burn every saved DSON file I have. But I certainly have not retained all of these files over the years and I would think if I delete a file in Poser these files should be getting erased too instead of building up till the end of time. If DSON can hijack and reroute the save location for a Poser function, then shouldn't it at least continue to work alongside it to manage the files it created?
The first part of this also insinuates "temporary" files - so are the auto_adapted files temps? If so, shouldn't they auto-delete? Or shouldn't I have an option for that? You can't bank temp files forever. That's ludicrous. And again I point out that many of my Poser Cr2's point to object files located in this insane directory. Why? Why disrupt Poser's traditional file storage to move files to another Poser runtime? DSON is running amuck with its functions and tossing files out and around like a drunk man littering as he breezes down the freeway.
An why are they duplicates in some cases? I literally have found duplicate Cr2 files as well as object bases in there - some with no name or garbage name rather and some matching figures and props I have used or saved. These are Cr2 files - not accessible by Poser since they aren't even in the proper file location and contain no means of loading them. What is that all about? I can fathom no reason a Cr2 should be located in the auto_adapted directory. You can't load from there in Poser. It won't appear in the library unless it's in the library figure sub-directory. When I convert a DSON file from DAZ to take to Poser I literally have a special DSON runtime established and set aside to save those files to. That's where they appear and where I load them into Poser from. Should not an option to clean or erase them have been included with the DSON application? Did the author not concern themselves with eventually clogging up the user's HD or storage? The delete file function in Studio and Poser wipe out all user-saved files - but DSON is writing its own files with its own purpose redundantly and all but pretty much hiding them within a random runtime directory of its choosing. This is just ridiculous and quite honestly I'm pretty peeved to discover 50+ GB of my drive is ate up by these "I don't know what" files that it would take me years to sort and figure out (as to what is needed and no longer needed). If I delete a converted file or transferred file using DSON, then shouldn't it be getting rid of all the connective files? This isn't a Poser issue. This is a DSON issue. DSON comes from DAZ. Just for once it would be nice to have someone come out and just say, "Hey our programmer was incompetent and half-did their job - our bad - sincere apologies."
The CR2 (or other file) that Daz Studio creates is not a full, Poser-format, description - it is a stub, it's sole purpose (as explained in that article) being to launch the DSON Importer. The Importer then creates these new files so that it doesn't have to run the (relatively slow) import process every time the scene loads. The name assigned needs to provide an unambiguous identifier, not to mimic the name of the original file (which may have been used more than once for different assets).
I'm pretty certain that I laid out that I know (at least loosely) how the conversion process works. I understand that. But why are the files scattered and repetitious? Duplicates in some cases. Why are "Cr2" files being stored. Poser only needs and can only use one Cr2 file. That Cr2 is the file located in the original transfer position (aka, the one I click in Poser to load the file into Poser). One Cr2 cannot reference another Cr2 of the same name. That said I realize you can load a Pz3 or scene file which contains multiple figures all with their own, individual Cr2 files. I'm specifically referencing one-character/one-Cr2.
For examples if I take "Shirt1" which is a Genesis 3 shirt in DAZ, and run the CREATE POSER COMPANION FILES option (and all the rest needed to convert it) and then save it as a DUF in my conversion directory inside DAZ, DAZ now saves that shirt in my conversion directory location. I go open Poser and refer to the DSON conversion directory and there is my shirt (PNG and Cr2). I click the icon in my Poser library and it loads the Cr2 (which actually redirects Poser to the DUF file). DSON Importer then sets about loading the shirt. So where in this process is it necessary for those auto_adapter files to come into play? If they are needed, then why aren't they being put with the DUF and Cr2 file in the initial/primary directory? That naming point you made is irrelevent, neither program allows duplicate named files in most cases and you'll be prodded (in Poser mostly) not to use identical names even if in a different directory. I don't see a reason for auto_adapter files to be getting placed.
Aside from this you've not commented as to why there is no cleaning feature for them - nor how we're supposed to cope with a never-ending build-up of DSON Importer related files like this?
The files you're talking about in your reply should be the primaries that get put in the conversion directory (DUF, PNG, Cr2). Those are the files relied on for the loading. Or should be. So if my Cr2 in my Poser library isn't the one needed, then why does it exist? I've got a "Shirt1.Cr2" in that library or I couldn't load it. So why would I have another "Shirt1.Cr2" over in the auto_adapted directory in a completely different runtime? Redundant and duplicate! Why? I'm sitting here looking at three I've found like that in just the last few minutes of digging. And why aren't the OBJECT bases stored with the coversion directory or at least in a "conversion" geometry file? Somewhere that makes sense? It's creating junk directories, files, and essentially sabotaging our runtime files by scattering elements of conversions all over the place. Lose one file and you're not going to be able to load the file. Wouldn't be so bad if there was order to the chaos and I could go to auto_adapted directory and simply locate the "Shirt1" file --- but no, I get "XIOEAK330039KDJSOIE?" file that's got "Shirt1's" necessary file labled within it as "wioejseu23890340?kdks.obj" or other nonsense. How could I ever even do a manual cleanup? Not possible. 50+ GB at this point to sort and figure out links to. It's an abomination of design at this point. No programmer should have done this.
Anyway I'm probably shouting to the walls at this point. I was a Beta tester for a time at the behest of Charles at Smith Micro --- and I got pretty much ignored there as well despite my points and concerns. Dev's don't ever listen to the people actually buying and using the software it seems. DSON Importer is dead as it is anyway, so I guess it's all moot at this point.
Understand that I didn't write the code, and haven't used the plug-in for a long time, and don't have Poser isntalled at the moment. When you create the companion files (the CR2 or whatever, the Python file, and the DUF file) the only one with any real content is the DUF* - the CR2 calls the Python file, which tells the importer to read in the DUF file. The importer then makes a more substantial CR2 fiel that has additional info to load more quickly. bevcause the save location is not the same as the original save location (because these are not user-facing files) it is possible for name-conflicts to arise.
* some of the Daz-supplied Poser fiels may well have material settings, as may files from other srtources, but those were not placed by the exporter - someone set up Poser materials and manually added the code for them to the Poser file, to be applied after loading the content.
Richard,
I had a couple of questions about your last reply if you don't mind clarifying them for me.
(1) You stated the DUF file is the only one wth real importance as the Cr2 that DSON Importer creates is really just a go-between that lets Poser understand the data in the DUF. I get that and that's exactly what I assumed was happening, but the auto_adapter files and the other locations I'm finding files are inside the Studio directories. So Studio (via the DSON Importer app) is creating these files. And when inside Poser resaving a Cr2 that's been imported, Poser cannot write to a DAZ directory --- so I'm still stuck asking why these files exist to start with. In simpler terms if Studio doesn't need anything but the files we install during product installation (say the files that come with a shirt we buy from DAZ and then install) then Studio isn't using these auto_adapter files for itself. And if DSON Importer is only directing Poser on how to use the original DUF files --- again, what are these other files doing? Surely someone with DAZ has an answer for this. If that person would supply an explanation it would making cleaning up un-needed files much more effective and safe. That's all I'm basically asking. I don't want to start random-deleting files or moving them to see if it crashes anything. If they're all just temp files, great - tell us so we can delete them. If they're needed, then an explanation is really important here.
(2) You made an addendum there at the last about Poser compatible files which I guess you're talking about the Genesis 1/2 content that had Poser specific versions/addons - but that's not what I'm talking about here. I'm specifically talking about modern, DAZ-only, Genesis 3 and 8 content. I convert it over to make a Cr2 file for Poser. I go to Poser and load it using DSON Importer plugin. I swap it over to Poser format and adjust any missing textures and whatnot, then I resave it via Poser so that I don't have to readjust everything again later to use it. So in a perfect world, Studio should only be making a DUF of the conversion and a Cr2 for Poser. Poser utterly relies on a base OBJECT file(s) and its own Cr2 file (which contains all data it needs including materials as you noted). So where does the auto_adapted directory and the other various treasure troves of files come from? Poser is not making them and putting them in the Studio directories. It cannot write there. It can only write to its own directory unless you manually save something elsewhere. So again, the DSON Importer is creating and scattering files to:
Users / User Name / AppData / Roaming / DAZ3D / Studio4 / temp (which has a Cr2Assets file in it?)
My selected Runtime Directory / Runtime / DSON / auto_adapted (where all the junk accumulates...50+ GB)
As mentioned, the auto_adapted is the biggest offender location...and we really, really need to know what's going with this so we (as users) can avoid build-up and clutter of our limited hard drives. Please inquire about this to the programmers if possible or whomever might have been on the Importer development team. Surely someone knows what is happening with this. Thanks again for your continued discussion on this and I appreciate your time and efforts.
I apologize if I offended any other users with my insistence on this thread remaining sort of closed to non-DAZ staff. I meant no insult towards anyone - and intended this request only to ensure that misinformation is not inserted or the topic does not veer off and derail the original purpose. As you all know that happens a lot in open forums. In this case the sensitivity of the discussion and topic simply needs to remain focused and informed to prevent bad information from causing users to damage their runtime files and lose data. My only intent was to preserve and protect users from invalid information.
I thought the topic was the CR2s created by the DSON Importer in the Poser folderstructure (which, as the documents linked above state, are a perfomance aid). Daz Stufio creats files for imported Poser content in the Auto_Adapted folder, again for performance reasons.
These are the fils created by the importer - doing other things to the imported content after import to turn it into native content (if I am following you) has no bearing on that. What I said above was about Genesis and Genesis 2 content because that is all that Daz supports - .it still applies to any other content you export companion files for and load into Poser.
Richard,
I honestly feel that I'm losing ground here. Does the person who created the DSON Importer for Poser still exist? Is there any means by which an explanation of the auto_adapted directory could be obtained so that we can determine what files in there may be deleted? They honestly should have no purpose. There is no need for Studio/Importer to produce multiple Cr2 files and that's what it is doing. It should also be putting base OBJECT files (needed for Poser) into a geometries directory specified for conversions or at least storing it alongside the Cr2 we create in Studio. It does not and instead tosses that OBJECT base into a nonsense named location with a nonsense name all lost in that auto_adapted directory. I thank you for the discussion on this but if you do not have the answer, it would be prudent to perhaps ask the programmer if possible. If anyone would know, that person would I think. And as said I think this answer would be extremely important to any DAZ users who use that importer feature. Please accept the fact that many, many DAZ customers still use Poser as their primary software. So inclusion of Poser users is always going to be important for DAZ. So this issue certainly affects a large number of DAZ customers and Studio users. I realize DAZ has washed its hands on DSON Importer and compatibe Poser content (due in part to changes made in Poser itself) but many continue to use older versions of both programs specifically to maintain compatibility. Anyway, just explaining why this is important to address.
Thanks again!
You seem to be again misunderstanding - Daz Studio itself does not create Poser-native content when creating companion files, that is handled by the importer when loading into Poser (to speed the process on future loads). The names for this need to be unique, hence the use of somewhat cryptic looking strings. This has already been covered, the developers have more than enough work to do without trying to write any more detailed technical specifications for a discontinued product.
There is a separate and distinct Auto_Adapted folder in the Daz Studio data folder that is written by Daz Studio when saving imported Poser-format content.