easily uninstalling products that were manually installed
second_technician_rimmer_9571136c47
Posts: 481
Is there a tool capable of handling [uninstalling products that were manually installed] this? Something that would let you select a folder with DSF's and the like and then, reading the reference from these, would delete all files concerned from the library? I have my own way to sort my library and the normal automated way doesn't really work for me, so I have to install quite a lot of stuff by dragging folders around.
Post edited by Richard Haseltine on
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
Sort of, it's a solution I'm currently working on by using DML against the SQL database to insert or delete database records with the metadata of products. It could be used to delete the installed files along with the database records too. It's not done yet but the other alternative is to use QT DAZ script to accomplish the same thing. As for products on the market now? I have not seen any.....
I am going to fave this post and when I finish my solution, I will check back here to see if you have this sorted out...
you could open the duf file in notepad and look for the paths for the stuff it uses
The idea would be not to have to manually check each duf/dsf/etc, Wendy :)
pfunkyfize, so basically this would work with anything you installed by dragging folders in place? If so... that's really something I will look forward to :)
So when you install your products, are you pretty much just opening an archive of content and then moving the stuff inside and placing them where you need it and bypassing the installation of GUID and metadata records through DIM?
that would be a handy script
My solution is command line oriented not GUI. So you'd have to type something like this at a command prompt:
C:> perl deletemyspecifiedcontent.pl
but that would be all.
You could have a directory and fill it with al the DSX files you wanted. My program then checks the folder and processes each DSX file and deletes the files specified from the metadata inside the DSX. . I write my solutions in the Perl programming language which is why it is a command line tool. The limitations of the tool is that it will read what's on a metadata file and act on the file at the specified path so if you have content that needs to be deleted but you have moved those files to another directory from what is specified on the DSX files, the script will not see them. The perl code can be read from any free open source Perl interpreter.
It started as a secondary solution for the database solution I'm wrestling with that I posted in the forum regarding postgresql use here. But I definitely see the fleshing out of the file side as an application for deleting stuff galore lol.
I'll check back on here when it's finished. I'm trying to wrap up this SQL project first so I'll check back with you guys in about a week to share what i have :)
Please let me know if you keep your files in the directory paths that are specified in the manifest.dsx file. You mentioned you move directories around so I'm thinking the files you want deleted will probably not exist at the specified path in the manifest.dsx file. Is that guess right?
I have my own library structure in the sense that data and runtime items are where they should be but all the folders which usually contain the DUF and such are not in the folders where they are initally meant to be.
For example, my g8f characters are in MY LIBRARY/PEOPLE/001 - CHARACTERS/FEMALE/G8F/ and then, there are subfolders by age, then ethnicity, then artist and THEN a folder with the character's DUF and finally, within that one, a folder named like the character with all the settings (materials, morphs, etc). So of course, automated install is out of the question :)
Ok, I see, so the scripts I have right now for my project delete files from the manifest.dsx file because it details all the exact paths of my content and I haven't moved the directories or customized the locations like you have. I think i will publish what I have in a week or so but in your case i think a solution can be made from it not necessarily using the manifest.dsx file and just using the references from DUF/DSON files in a directory....
As I look further into a solution for this I see why no one has made a script that uninstalls content the way you have it set up.
The runtime\textures files referred to by the assets in the DAZ .DUF files can be found because they are explicitly referenced in the user facing DUF files. However, the data\ directory files are not referred to explicitly in the user facing duf files so while all the DUFs and texture files will get successfully deleted/uninstalled, the data directory files will not, leaving clutter orphaned data files behind.
The way my scripts are working is that it takes the manifest.dsx file which has all the files associated with the packaged content listed with their base paths and deletes each of those files using those file paths. It works because I didn't customize the folder paths like you have done with yours so the paths to all my packaged assets are accurate. The manifest file comes with all DAZ downloads via DIM so that's easy to get for all your DAZ products. Products from Renderosity or other content stores do NOT come with manifest files. I use the Content Package Assist to make those zips from other stores look like DIM install files and a maniifest gets created once the Content Package Assist does its thing.
Another red flag for why uninstallation by referencing file names inside user facing DUF files is that an asset often refers to a product file that is NOT part of the intended product you want to uninstall. So when my script reads those files, it will zap the other product files which you did not intend to be uninstalled. That is a bad bad thing to do. There are way too many permutations to account for in this scenario so it's just advisable to not do it that way.
The best way to uninstall the files in the way your content library is setup is by keeping your own manifest file that lists the paths of all the files associated to the package once you're satisfied with where all your files were placed. I realize that's a big extra step to do since you have to do it with each product you install but it guarantees the ability to remove those files without removing something you didn't intend to remove. making a manifest file is part of the reason why i use the Content Package Assist program- to make a cataloged manifest file as well as install it into my content library. You could still use the CPA to make the package but you wouldn't have to install it via DIM just install it the way you currently do but you would at least have a manifest file to save somewhere. The nice thing about Renderosity products is that they have a readme file you can see on the product's page and it lists out all the files in the package creating a manifest of sorts. However the other stores may not have such a setup....
Yeah, I think I will publish what I have sometime late next week.
Okay, now thanks to you I can see the whole picture. It means though, that my huge library of aready manually installed and arranged products can't benefit from that sort of uninstall.I would have to do it all over... serves me for trying to get creative ^^;
No, you wouldn't have to start all over. It's ok how you did it - do you have a lot of DAZ products with manifest files?
Do you have a ton of oproducts from other stores?
I'll write up an example how my script can be used in your instance. I just think going forward you should catalog each product's asset paths as it reflects your content library to a text file so you can use an automated way to remove your products when you want and be confident the right files are being removed.
I have quite a few daz products and also from other sites. Mostly Rosity but also some by independant small stores. Thanks for the help, I really can use it :)
I'll try to wrap my mind around the way this works... always best to go to bed in the evening with some new stuff learnt :)
It would be nice if such a script didn't blindly delete files. If it could give you a checkbox list of files before it deleted anything, that would be better. Another improvement would check for cross-references, to see if a file being deleted is used by another product, but that would probably take longer to process.
Sorry NO, this script doesn't blindly delete ANYTHING - if you look inside the manifest.dsx file, you'll see the exact files listed that will be targeted for deletion. It would be a useless script if it just deleted 'anything' it wanted.
This is also NOT going to be a GUI solution so no checkboxes/radio buttons/fields - you get the picture. It is a Perl program that is part of my workflow that is designed to batch delete large quantities of files driven by a parameter file ( eg. the manifest.dsx file)
This is going to be a free solution and if you are not savvy with command line processing then this script is not for you.
Here's that example I was thinking of that would probably work for you if you're deleting a DAZ product:
Let's say you have a DAZ product, a G8F character,with the DIM zip and inside you see the manifest.dsx file along with everything else. Then you install it into your content library leaving the Runtime and Data folders in their place but moving the user facing DUF files into the folders you described to me a few posts up. After a while, you decide to uninstall the product.
1. Go to the folder you want to get rid of that contains the character itself and all those preset folders. Since all the files are organized in subdirectories beneath that character directory, just select that character directory, hit 'Delete' button and you have 'uninstalled' (lol) that part of the product. Since you deleted the main character folder, you deleted all the files subdirectories underneath it too.
2. Next, take the manifest.dsx file of the product you're uninstalling and copy it into the script directory that will come with this script.
3. At a command line/prompt, type in the following - perl UninstallProductAssets.pl
And that's it!
The script will look through all the files in the manifest.dsx and delete them one by one. Since you left the Runtime and Data directories alone, it will find them and delete them successfully. When it tries to find the DUF files it won't be able to because you've already deleted them in step 1. It would not have found those files anyway because you have them in customized locations from the DAZ specified structure. But hey, they were successfully deleted in step 1 so no problem!
I'll write up the way you would use the script with Renderosity products later.
One solution I thought of, make sure to keep an archive of your modified installer. If you want to remove it, drag drop the files into your library, overwrite when asked. Then right click undo copy. It should remove the files. At least on a windows OS, not sure if that would work on a mac os.
Also, when I meant that you left the Runtime and Data folders alone, I meant that you didn't put those directories into a customized structure like you did for the DUFs. That's good that you left those directories alone.
If you hadn't customized the folder structure and left everything in their DAZ intended places, all you would have had to do was just put the manifest file into that script folder, invoke the script and everything would be deleted in one go. But it's still doable the way you have it set up.
Ah, so this doesn't work without a manifest.dsx file? I guess products installed by hand are out of luck then.
It will work with hand installs - IF you follow a couple of steps that will be shared later on. Keep your eyes peeled...
That has given me some ideas. Is there a way to rebuild the manifest? So, there would be two tools, a manifest builder, and a manifest deleter?
Absolutely...
My script that I'll publish is the deleter that uses a manifest - and it won't be just the manifest.dsx you can use, it can be any ASCII text file with a list of files associated to a product.
There's a product out there called Content Package Assist that creates a DIM file from content and creates an IM zip file that contains the manifest. My suggestion to the poster would be to take the content he has, set it up how he wants to see it the way he envisions it in his content library, then create a new installer package with the CPA that also makes a manifest file. The user then has the option to install it with DIM -OR- install it manually without using DIM and if he wants to delete/uninstall the product all he would have to do is throw the manifest file that the CPA made into my script's staging directory which acts like an automated file ingester and all the associated files inside the manifest will get deleted.
The poster already said that he installs manually and doesn't use DIM, hence this solution is for people who do all their installs by hand because they don't want to use DAZ Connect/DIM/DAZ Central for whatever reason. So without some sort of manifest file, it is awfully hard to remember what assets let alone their paths are associated with a product to target for deletion
A solution for people who don't mind using the DIM to install their products with DIM that have customized paths... (And no this wasn't meant to be a commercial for the CPA)
1. Purchase the Content Package Assist at DAZ.
2. Create a staging content library to be used just for making DIMS and have the CPA point to it. If you don't know how to do it I can show you.
3. Whenever you buy a product from anywhere, take all the zip files (not the templates or PoserCF zips unless you use Poser as well) and dump it into your newly made staging content library.
4. Move the files into new directories inside your staging library to the way you want to see it in your real working library. Careful, no typos when making the new directories. DO NOT move the Runtime and Data directories anywhere or change the locations of their contents.
5. Use the CPA to make the new IM file (I would name it something else rather than 'IM' call it 'CUSTOM' or 'CPA' or something indicative of anything other than 'IM'). A new manifest with the new customized paths gets created automatically. Clean up for the next product by deleting all the stuff you made in the staging content library. You want it clean before you make another product.
6. Use the resulting new IM-like zip file and throw it into the DIM application where downloads are ingested and install the content.
7. Your new content is now installed - and the way you like it! side benefit, you get a product name in the Content Library section and your LOCAL USER product will not be a gargantuan MESS.
8. When it's time to uninstall, open the DIM and hit the uninstall button for the product you made and all files associated with the custom pathed product will be deleted.
I think that CPA iis something like $15-$20 buy on DAZ but it's worth it in my opinion.
Of course, if you are avoiding installing using the DIM, then just install the new zip manually and use my script to delete your stuff that requires a manifest file.
Yeah, I liked the fact that you can uninstall products installed with CPA, but have switched to Content Wizard for it's ability to create metadata.