Hello!
We have been running CMOD for Multiplatform in a cache-only mode for a very long time, and are currently on v9.5.
While doing a large amount of exports with
arsdoc get, I came across some documents that appear to have been corrupted somehow, that could not be extracted. They can also not be opened with the thick client nor with the Content Navigator web gui.
Using arsdoc get with option -n makes it fail on the second document in my selection, and when doing it without the -n flag, it fails on the eleventh. That is probably just an ordering issue, though. I don't think that's worth investigating. I've done single-document queries so I know exactly which documents are damaged.
The messages from arsdoc while retrieving are:
2019-07-24 12:08:26.270740: (2): ARS6073I Retrieving document for userid 'ADMIN' ...
2019-07-24 12:08:26.294203: ARS6096E Retrieve unsuccessful
2019-07-24 12:08:26.294313: ARS2094E The server failed while retrieving a document
There is nothing in the system log when this happens. Using the native windows client or the web client (Content Navigator) on the corrupted documents also logs nothing into the
System Log.
Using
arsdoc query with the
-D flag, adds this information to the output:
,801FAAB,148456,36678,976552,243727,U,O,0,1,0.
Am I correct in thinking that the compressed document should be somewhere in
/arscache/cache1/retr/HDB/DOC/801FAAB ?
Example:
lrwxrwxrwx 1 archive db2adm 38 Apr 29 2016 /arscache/cache1/retr/HDB/DOC/801FAAB -> /arscache/cache8/19130/HDB/DOC/801FAAB
-r-------- 1 archive db2adm 7798612 Apr 01 2012 /arscache/cache8/19130/HDB/DOC/801FAAB
ARSMAINT has no complaints about the links, and the permissions and ownership on the retr link and the actual file it points to are correct, and the link target can be read with tools like wc or strings, so there is no underlying I/O error.
So, I guess what I'm wondering now is how to find the offset and length in the DOC file. Could it be the second (148456) and third (36678) parameters in the "Document handle" that the -D flag provides to the arsdoc query output?
If so, I guess the only thing I need to figure out is how to do an OD77 decompress "by hand"
- Is there a command line tool for that?
Obviously the document retrieval in the clients should work if the above works, but I still would like to give it
a final try to just to be absolutely certain that these documents are lost forever.
Any further ideas? Anyone knows what _all_ the parts of the "document handle" are?
Thanks!
Matt