DIM problems uninstalling on a system different than the install system...

CypherFOX

Greetings,
So. I've had a epiphany about the DAZ Install Manager and multi-machine use...

I've installed a lot of stuff with DIM, on various boxes, all pointing to the same My Library that is synchronized across all of the systems. Unfortunately, one thing I _did not_ realize was that the install is tied to the ABSOLUTE path of the file on the system it was installed on.

So, for instance, say I install 'Evening Gown 2 V4' on my work Mac, and it stores it in /Users/fbar/SyncDirectory/My Library/Runtime/...

Then, later on, I want to uninstall. But I'm sitting on my home Mac. DIM will happily tell me it uninstalled. But it won't do a darn thing other than remove the installed DSX file, because on my home Mac, the files are in /Users/fb/SyncDirectory/My Library/Runtime/... .

I had [strike]thought[/strike]...let's use hoped that it treated the install directories as relative to the install path configured on each instance of DIM. So on my work machine, the install is pointed to /Users/fbar/SyncDirectory/My Library. So it should store something like {parent}/Runtime/... and then each individual machine could do uninstalls or installs as it wanted to. I thought this because DAZ had just gone through a change like that to make the Runtime work that way on DAZ Studio, as they realized that relative-to-base is vastly more useful than 'absolute path'.

This same problem probably affects using DIM to install on external drives that are shared between different operating systems (Install on a Mac, uninstall on a Windows box...? Probably not going to work.)

My problem is that I've installed on all my boxes, without being aware that I needed to be consistent or uninstalls wouldn't work. So when I sat down on my Mac laptop and uninstalled some 30GB of V4 content, intending to move it to a different non-synchronized Runtime, it only actually uninstalled 3GB of real data. The rest was left orphaned.

I don't know if this is a bug that DAZ would care about. I do know that it explains why my uninstallation of a product that I was dissatisfied with, and got a refund for, never 'took', and I had to root around and delete all its pieces by hand. I probably just uninstalled it from a different computer than I installed it on.

I think it would affect external drive users, but...maybe not deeply. I'm an edge case, and always have been. :-/

I hope this helps someone else who might be trying to understand strange uninstall behavior.

-- Morgan

Richard Haseltine

Did you try installing on the machine you were at, to the same location, and then uninstalling? I'vea feeling that may not work as it may think the files are meant to be there still, but it's worth trying.

jestmart

DAZ Studio has not changed anything recently it has always used relative addressing. If DIM had actually installed the files on all your computers than the associated manifest files would be correct. It sound like you copied and pasted from one computer to the others so of course the manifests are wrong. Don't blame DIM for a bug that doesn't exist, it has to use relative addressing to be sure it updates or uninstall the right files.

CypherFOX

Greetings,

jestmart said:

DAZ Studio has not changed anything recently it has always used relative addressing. If DIM had actually installed the files on all your computers than the associated manifest files would be correct. It sound like you copied and pasted from one computer to the others so of course the manifests are wrong. Don't blame DIM for a bug that doesn't exist, it has to use relative addressing to be sure it updates or uninstall the right files.So...I'm talking about DIM, not DAZ Studio. My reference to DS was about lessons they learned when putting the .DUF format together. And I'm suggesting that DIM is using absolute addressing to determine if it should uninstall, not relative addressing. But when you talk about copying and pasting, I can understand that this isn't your forte.

Let's put it this way: I do not believe the software had to behave this way. Whether it is a bug or not is up to interpretation, and that's okay. I pretty much said as much in my initial post. There may also be, as I discuss below, other factors involved.

Did you try installing on the machine you were at, to the same location, and then uninstalling? I'vea feeling that may not work as it may think the files are meant to be there still, but it's worth trying.

Yeah, I did try that, and it didn't uninstall it, to my dismay. It seemed to be...aware that the files existed before it installed, and so didn't uninstall them. Maybe it's reference counting or something, which might be a second reason it's having issues. (The files got orphaned because they didn't get deleted off the absolute path, and then they got refcounted up to 2 when I did the reinstall, causing them to not be uninstalled... Complex, but very possible.)

Out of curiosity, if you have a moment, could you look at your own My Library/InstallManagerFileRegister.json...? Does it have a lot of lines with:

[ "...", 2]

I was thinking maybe the ", 2" was where it tracks the counts. Just a wild guess, backed by doing an install of one of the affected products and seeing its files added to that .json file with a ", 2" for each of them.

(My InstallManagerFileRegister.json is 11M long, and (since I'm now 90% certain about it being refcount storage) the files with the most refcounts are all related to AprilYSH hair, with 12 references. :) So I've probably installed 12 packages which create the same file, e.g. people/genesis/hair/aprilysh.png )

So theoretically I could snapshot the IMFR.json file, install all the affected items, write and run a small script to find the new items that were added to the JSON by the installer, reduce their refcount to 1, save it back out, and then uninstall them all. With a reference count of 1, DIM would happily delete the files believing that they're not used anymore.

That would probably be the easiest solution to the data situation I find myself in...

-- Morgan

namffuak

jestmart said:

DAZ Studio has not changed anything recently it has always used relative addressing. If DIM had actually installed the files on all your computers than the associated manifest files would be correct. It sound like you copied and pasted from one computer to the others so of course the manifests are wrong. Don't blame DIM for a bug that doesn't exist, it has to use relative addressing to be sure it updates or uninstall the right files.

Ah - actually, Studio uses relative addressing - but DIM uses absolute path names. If you hover over an installed item, it shows where it was installed to - including (on Windows) the drive letter. If you right-click and select 'show installed files' the to line shows the pathname of the directory the product was installed to, followed by the relative locations within that directory for everything installed.

Cypherfox, the only thing I can suggest is to try standardizing on one system to do all the install management - not sure how that would impact your processes though.

CypherFOX

Greetings,

namffuak said:

Cypherfox, the only thing I can suggest is to try standardizing on one system to do all the install management - not sure how that would impact your processes though.

Yep, I know that now. :) I installed on a variety of systems (Windows and two Macs, each with a slightly different username for me) and so I'm in a world of data issues right now. Going forward, I probably will just install on my Mac laptop, having learned this particular issue, but I still have to figure out a way out of the mess I've gotten into with orphaned files, etc...

I think reinstalling, tweaking the InstallManagerFileRegister.json for the newly installed files (actually it looks like files that are single-reference don't get entries in it, so it might work to save it off, install, restore it, and uninstall) is my best bet to get out of the situation my library has gotten into.

...but yes, going forward, making one system the 'install/uninstall here' system is probably necessary, albeit frustrating. (I have higher bandwidth at work, for example, but I won't always have access to that system, so it can't be my Source Of Truth.)

-- Morgan

Richard Haseltine

Yes, I thought that was what would happen - the .json file is, as you suspect, for tracking files which are used across multiple products and so shouldn't be removed until the last product is removed. As I recall there was some work done in this for one of the updates, with an update function to cope with pre-installed (non-DIM) content but I wasn't absolutely sure how it worked - if you dig around Rob did explain, and he may have said something that will help you (I can't recall which DIM update it was - relatively recent I think).

namffuak

Cypherfox said:

Greetings,

namffuak said:

Cypherfox, the only thing I can suggest is to try standardizing on one system to do all the install management - not sure how that would impact your processes though.

Yep, I know that now. :) I installed on a variety of systems (Windows and two Macs, each with a slightly different username for me) and so I'm in a world of data issues right now. Going forward, I probably will just install on my Mac laptop, having learned this particular issue, but I still have to figure out a way out of the mess I've gotten into with orphaned files, etc...

I think reinstalling, tweaking the InstallManagerFileRegister.json for the newly installed files (actually it looks like files that are single-reference don't get entries in it, so it might work to save it off, install, restore it, and uninstall) is my best bet to get out of the situation my library has gotten into.

...but yes, going forward, making one system the 'install/uninstall here' system is probably necessary, albeit frustrating. (I have higher bandwidth at work, for example, but I won't always have access to that system, so it can't be my Source Of Truth.)

-- Morgan

You might try this - run your install, then go into setup in DIM (gear icon) and select the 'install' tab. Then right-click on the individual install path(s) and select 'Fix installed file registry'. That is the change Richard referenced.