Incorrect metadata values for CHECKSUM and FILESIZE - DIMENSIONS

Drew Benson's picture
Drew Benson asked on April 9, 2015 - 9:00am | Replies (2).

Wondering if anyone has come accross this issue? (It's not a show stopper but has got me scratching my head)

I am trying to "migrate" some Items from an existing Dimensions Product into a new Product.
NB I am in essence cloning "part" the old Product.
I do actually want to create new CI/items rather than variants of the existing CI/Items.
The new CI/Items will all be V1 with no history etc in the new Product.

So pretty simple steps:
1) Get copies of the Items I want
2) Load them into new Product
3) Prove they are identical *see below
4) Get on with my life.......

As I did a direct get from old and load to new I "know" they are identical I am just "documenting" the proof for the end user.

I have set up a few scripts to:
a) Run diff/compares between the fetch from New Dimensions (O/S directory structure) vs fetch from Old Dimensions (O/S directory structure) and saved report (They are identical :-) )
b) Run detailed directory listings showing dates, sizes etc and produced a compariosn report. (They are identical :-) )
and finally:
c) Produced seperate output from Dimensions listing all (relevant) Dimensions metadata and produced a comparison report......... THEY ARE DIFFERENT!!!

For some files (a very small subset) the Dimensions metadata for "CHECKSUM" and "FILES SIZE" don't match!!
(Revised Date (UTC) DOES match).....

I have loaded the offending files a few times and they always produce the same values for this metadata (& the file size value ALWAYS matches the O/S file size).

So basically the "old" values for this metadata is "wrong"!!!

I have no way of reproducing this (as all experiments now produce "correct" values)....

The only thing I can think is that this is in some way connected to the various character translations between UNIX and Windows (as all the files "could" have been via UNIX at some point).

As mentioned it's not a show stopper (as I KNOW the files are OK) but if anyone has any ideas/experience I'd like to know!!


2 Answers

Bob Aiello's picture

hey Drew - are you sure that this is a problem with Dimensions? I have seen this kind of behavior in ClearCase and then, upon investigation, we saw the same behavior with files on the operating system having nothing to do with the version control system!

I saw this behavior on AIX dfs (copying from dfs to non-dfs file systems) and on NAS devices (turned out to be a CIFS configuration issue).

What version of Dimensions are you using?
What OS(es)?
Have you tried calculating some hashes on files on the OS outside of Dimensions?

Bob Aiello, Technical Editor

Drew Benson's picture

Hi Bob thanks for response

It's an issue with the "historic" metadata that Dimensions holds.

The "historic" is the key here...

All the files where this issue has occured are basically pretty old files - and in reality I have no way back to conditions at the time they were created (everthing works and all metadata generated now is consistant)

We are currently on Dimensions 12.2.2 (Server and Client)
It's running on a Server with Windows 2008
DBase backend is ORACLE on a UNIX box
The Clients are Windows7
We do use UNIX but only for gets/deployments so no "writes" ie The files wouldn't have been checked in (creating the metadata) from UNIX.

However in the life of these files:

Client O/S has gone from Windows XP to Win7
Dimensions has been upgraded at least once (12.1....)
Dimensions Server is a different server - so could also have upgraded O/S
Backend ORACLE may have been upgraded...
(DBase may have been migrated?)
Backend UNIX O/S may have been upgraded....

As per above - everything works - the true content of the files is correct it's just that the two attributes for the offending files is holding shonky values.

In this age of precision, n-th decimal place accuracy the only "solution" I have is :-

SOD IT!!! It's just one of those things! :-)








CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.