It's all about the answers!

Ask a question

Data to track sandbox is inconsistent error - what can cause this ?

Nicolas Dangeville (31622325) | asked Jan 20 '15, 3:05 p.m.

A Customer of mine sees this very often (they use RTC 4.03).

In addition, repairing takes a lot of times (several hours I've heard).

I very rarely see this error myself, so it's hard to compare with what I experience. I think it is worth to investigate the root cause of this error.

What exactly are the criteria to raise this error, and what are the common causes ?



2 answers

permanent link
Lily Wang (4.9k714) | answered Jan 20 '15, 8:08 p.m.
Hi Nicolas,
The "Repair Metadata" is happened when sandbox metadata is corrupted or out-of-date, which will re-create the ".jazz5" directory in the sandbox.
You may need to ask your customer what they did for the sandbox before this problem was happened. The Eclipse client log is also helpful to determine the problem.

Geoffrey Clemm commented Jan 20 '15, 11:33 p.m.

I believe Nicolas was asking what user actions or system faults could cause the sandbox metadata to be corrupted in this fashion (so he could ask the customer "Did you do x or y or z", or "Did x or y or z happen").   Note that someone else using the same workspace does not cause this error ... that produces an "out-of-sync" error message, which is fixed by reloading.

permanent link
Evan Hughes (2.4k1318) | answered Jan 21 '15, 10:31 a.m.
 It is very rare for the sandbox metadata to become corrupted. As Lily mentions in her answer, it would be useful to know what the customer was doing immediately before the sandbox became corrupt. 

In the few occasions I've seen the sandbox metadata become corrupt, it's because the client was killed rather than being allowed to shut down cleanly. The client caches some metadata, so it needs a chance to flush those caches. In my experience those cases occur when the machine loses power, there is an OS crash, or the user kills the client with Task Manager (or something similar). 

Metadata corruption can also occur if the filesystem isn't consistent between runs of the client. The disk could be corrupt, it may be a network FS that doesn't support locking (e.g. NFS), or users may be modifying data manually. We've only seen this rarely, however. 

Since your customer is seeing this problem repeatedly, please ask them to raise a defect so we can get to the root of the problem. This is not expected behaviour. 

Your answer

Register or to post your answer.