Meaning of the DIM file names - does IM00021306-01 mean version 1?

LynZem

I searched for this topic many different ways, but maybe didn't use the correct jargon - I found nothing.

Traditionally (since 2008), I have been downloading DAZ content manually, storing in my own DAZ_Download hierarchy splitting up clothes, people, props, etc.

Today, I used "DAZ Install manager" to download all 1556 things I've bought (or gotten free) over the years. A bit of an eye opener at 43GB just for DAZ content! I did this in part as I prefer the ZIP form to the EXE, plus I'm trying to understand & track changes. Some times I talk to folks online, and some one says I need version 1.1, not 1.0 of a content object.

My question centers on that I am seeing a size & content difference in many file, despite no name change.

A simple example ( http://www.daz3d.com/honey-bolt ):
- IM00021306-01_HoneyBolt.zip downloaded manually on 9-Mar-2015 is 86,675,694 bytes
- IM00021306-01_HoneyBolt.zip downloaded by DIM today (1-May-2015) is 84,414,387 bytes

Comparing the Content of each, the 1-May has new object files (new hands?), and a number of related changes. That seems like an important change, should the file name have changed to IM00021306-02_HoneyBolt.zip? or am I making silly assumptions? How is content version tracked? I had not planned on using DIM to install everything, as I always put into my own locations. But I am still hoping DIM can detect changes in content downloaded, even if not installed by DIM.

(FYI - I am a programmer by trade, so used to tagging builds with some form of rev code ...)

Richard Haseltine

The name stays the same - otherwise DIM wouldn't be able to tell that it was an update, and the old version wouldn't be overwritten leading to potential bad installs.

namffuak

The -01 and -02 have nothing to do with version or revision numbering. They are for products that have multiple components, like the recent ground shaders product that was split into two downloads - sku 21468, package id 1 and 2.

Esemwy

I'm pretty sure that DIM just uses the UserOrderDate and the InstallerDate from the manifest (.DSX) files to determine when to download and install updates. There's a couple of version number attributes in the manifest and supplement files, but those just seem to be versions for the XML formats.

There might be some version information in the CMS, but I don't know how it would get there unless it's part of the DIM protocol. Everything else for the CMS seems to be handled with a supplemental DSX and script.

namffuak

Esemwy said:

I'm pretty sure that DIM just uses the UserOrderDate and the InstallerDate from the manifest (.DSX) files to determine when to download and install updates. There's a couple of version number attributes in the manifest and supplement files, but those just seem to be versions for the XML formats.

There might be some version information in the CMS, but I don't know how it would get there unless it's part of the DIM protocol. Everything else for the CMS seems to be handled with a supplemental DSX and script.

DIM actually uses a file hash to determine if the version on the server is different from the version you've downoaded, whether you have installed it or not. Nothing DIM-related lives in the CMS/Postgres database.

mjc1016

namffuak said:

The -01 and -02 have nothing to do with version or revision numbering. They are for products that have multiple components, like the recent ground shaders product that was split into two downloads - sku 21468, package id 1 and 2.

That's what I thought, too...especially if you look at something like M4 or V4...there's quite a few files there. They all have the same name with -01, -02, etc indicating the different parts...like the PowerLoader is one part and the base files are another.

LynZem

Richard Haseltine said:

The name stays the same - otherwise DIM wouldn't be able to tell that it was an update, and the old version wouldn't be overwritten leading to potential bad installs.

Many thanks - that makes sense. I remember in the OLD days, the numbers would increment, so 8622_10 (V4 basic wear) becomes 8622_21 after an update, and so on.

So will DIM detect the need to download an update if I have only downloaded, but not installed the module? That was really my goal in downloading 43GB this morning - to detect when things change. For example, DAZ didn't notify me about the Honey Bolt change. In the old days, one could look at the my_downloads web page and when stuff needed update, it would get requeued with a reset download count.

That web function seems to have disappeared, so I'm guessing DIM is the replacement.

namffuak

LynZem said:

Richard Haseltine said:

The name stays the same - otherwise DIM wouldn't be able to tell that it was an update, and the old version wouldn't be overwritten leading to potential bad installs.

Many thanks - that makes sense. I remember in the OLD days, the numbers would increment, so 8622_10 (V4 basic wear) becomes 8622_21 after an update, and so on.

So will DIM detect the need to download an update if I have only downloaded, but not installed the module? That was really my goal in downloading 43GB this morning - to detect when things change. For example, DAZ didn't notify me about the Honey Bolt change. In the old days, one could look at the my_downloads web page and when stuff needed update, it would get requeued with a reset download count.

That web function seems to have disappeared, so I'm guessing DIM is the replacement.

DIM works off a file checksum hash stored in the zip file; if the hash in your download doesn't match the hash on the DAZ server you will see the product show up as a product update on the DIM download tab. The file hash is stored in a product manifest when you do the install, so it is still available if you delete the download after the install. The product manifest is stored under your documents and settings path (I'm on an XP machine right now, so I can't dig out the full path).