Daos- Catalog: Hat jemand schonmal die $DAOSTicketList- Attachments analysiert?

[Tode]

Eine Frage, die immer wieder beim Blick in die DAOS- Verzeichnisse aufkommt: In welche Mail- Datenbank gehört denn dieses 700MB Attachment?

Leider liefert IBM ja kein Tool mit, mit dem man die Antwort auf diese Frage einfach liefern könnte.
Nun habe ich überlegt, selbst ein solches Tool zu schreiben.

Vereinfacht gesagt würde ich:

- Alle (oder gewählte) Datenbanken im Catalog oder per DBDirectory durchlaufen
- per tell daosmgr listnlo mail\Pfad.nsf -o pfad.txt alle nlos für die Datenbank in ein file schreiben
- die Informationen "aggregieren" in "nlo- Dokumente" (zwei Felder: key: nlo- Name, dbs: alle Pfade, in denen des nlo vorkommt)

Nun wird dieser Vorgang - je nach Datenbank- und Attachmentzahl etwas länger dauern...

Deshalb dachte ich: Der Domino verwaltet die Info ja auch irgendwo und habe mir mal den Daos- Catalog angeschaut.
Ich habe mir eine lokale kopie gezogen und mal die Dokumente darin analysiert. Das sind im prinzip Container mit einem einziger Item namens "$DAOSTicketList". Dieses enthält ein Objekt...

Hat sich jemand das schonmal angeschaut? Allzu kryptisch dürfte der Aufbau ja nicht sein, die Verwaltung muss ja performant sein...
Aber es scheint sich um irgendein codiertes Format zu handeln (hoffentlich nicht mit der Serverid verschlüsselt)...

Hier ein XML- Auszug aus so einem Dokument:

Code

<rawitemdata type='3'>
BgABAAAAEQCyoAIATgMAABoAAAAAAAIACAABAFr3AAA56QQAAAAAAAAAAABGOTRGNEFERjkwOUYz
NUZFRUZGNjM0MzQyREJENDcwNjlFMDQ4QjlGMDAwNEU5MzkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAB0AAAC2AAAAGgAaAAAAAAACAAgAAQB69wAAYCEFAAAAAAAAAAAAQUY2N0UxODRGQUZE
MERBRTI5NDQwQkVBQUY5OUEyQUZCRTZGNDMyODAwMDUyMTYwAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAdAAAAtgAAABoAGgAAAAAAAgAIAAEAfvcAALaqAgAAAAAAAAAAADhEQkFDNjBGMjM2
RTkxNzY2MDU1MkU3NTQ0QzcyMzMwQTk3RUM0MDkwMDAyQUFCNgAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAHQAAALYAAAAaABoAAAAAAAIACAABAIL3AAD/awQAAAAAAAAAAABGOTUzNjI0MTI1
OUU0NjFERTZBNzYwODFCOTY3ODlFQ0Q5QzgzRUJEMDAwNDZCRkYAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAB0AAAC2AAAAGgAaAAAAAAACAAgAAQBW+AAAmcueAAAAAAAAAAAAMkUzMjkxNjE1
...
AAAAGgAaAAAAAAACAAgAAQDCKAAAx0EQAAAAAAAAAAAAQzUxNUNBREMzRjg5QjEwNjBFMEI4Qjg0
QUI4RDA0OEU5QTVBOTk2MzAwMTA0MUM3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAA
tgAAABoAGgAAAAAAAgAIAAEARioAALpMBAAAAAAAAAAAADgxNDdGMzNBMEMwNTc3QzU3RDcyQkY0
RjFEN0E3NDE4REZENURBOTUwMDA0NENCQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAA
ALYAAAAaAA==
</rawitemdata>

Wäre ja cool, wenn man an die Info da drin rankäme...

[pram]

Die Daten sind Base64 codiert:

Code

�
����² �N��
�������
�Z÷��9é���������F94F4ADF909F35FEEFF634342DBD47069E048B9F0004E939��������������������������������¶����
�������
�z÷��`!���������AF67E184FAFD0DAE29440BEAAF99A2AFBE6F432800052160��������������������������������¶����
�������
�~÷��¶ª���������8DBAC60F236E917660552E7544C72330A97EC4090002AAB6��������������������������������¶����
�������
�‚÷��ÿk���������F9536241259E461DE6A76081B96789ECD9C83EBD00046BFF��������������������������������¶����
�������
�Vø��™Ëž���������2E3291615����
�������
�Â(��ÇA���������C515CADC3F89B1060E0B8B84AB8D048E9A5A9963001041C7��������������������������������¶����
�������
�F*��ºL���������8147F33A0C0577C57D72BF4F1D7A7418DFD5DA9500044CBA��������������������������������¶����

Es kommen ein paar IDs vor, evtl hilft dir das zumindest für die Suche weiter...

/edit: Encoing und Zeilenumbrüche nochmals anders gesetzt. Man erkennt eine gewisse Blockstruktur
Gruß
Roland

[Tode]

Vielen Dank für die Mühe. Die Base- 64 Konvertierung passiert wahrscheinlich beim exportieren per XML. Werde mal einen Agenten schreiben, der versucht, ob man da irgendwie über "embeddedObjects" rankommt und das speichern kann...

Sieht ja so aus, als stünden da die Filenamen der Daos- Files drin. Und wahrscheinlich auch noch die UNIDs der zugehörigen Dokumente, u.u. noch die Replik- ID...

Mal schauen, ob ich mal Zeit finde, da weiter zu forschen...

[eknori]

evtl hilft das ... http://noteshexe.de/blog/?p=2751

[Tode]

Interessant @Ulrich... Aber reduziert nicht wirklich die Dauer der Abfrage, wenn man rausfinden will, in welcher Datenbank sich ein Attachment befindet.
Natürlich erhält man im Gegenzug sogar noch genauere Informationen darüber, in welchem Dokument das Attachment ist, aber das ist -in meiner Praxis- meist nicht die Frage (kann aber interessant sein, um herauszufinden, wo genau ein "defektes" oder "fehlendes" NLO sitzt um zu entscheiden, wie gross die Anstrengungen zur Wiederherstellung sein müssen)

[pram]

Habe mich soeben auch mal mit der $DAOSTicketlist beschäftigt und möchte meine momentane Erkenntnis teilen.

Analysiert wurde folgender Block

Code

	6B 34 00 00 1A 00 00 00.00 00 02 00 08 00 01 00 	; 000 k4..............
	52 0F 09 00 48 8E 01 00.00 00 00 00 00 00 00 00 	; 001 R...H...........
	46 32 36 34 34 43 33 39.37 45 32 46 31 38 31 43 	; 002 F2644C397E2F181C
	32 37 36 33 31 42 36 45.36 43 34 32 39 30 46 37 	; 003 27631B6E6C4290F7
	43 38 31 30 35 30 38 33.30 30 30 31 38 45 34 38 	; 004 C810508300018E48
	00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 	; 005 ................
	00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 	; 006 ................
	00 36 01 00 00 1A 00 1A.00 00 00 00 00 02 00 08 	; 007 .6..............
	00 01 00 9A 0F 09 00 53.78 2E 00 00 00 00 00 00 	; 008 .......Sx.......
	00 00 00 32 44 42 36 30.39 43 41 30 43 35 33 35 	; 009 ...2DB609CA0C535
	35 33 41 38 31 31 32 32.42 45 44 30 41 33 37 46 	; 00a 53A81122BED0A37F
	46 32 44 39 46 33 35 38.35 42 39 30 30 32 45 37 	; 00b F2D9F3585B9002E7
	38 35 33 00 00 00 00 00.00 00 00 00 00 00 00 00 	; 00c 853.............
	00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 	; 00d ................
	00 00 00 00 36 01 00 00.1A 00 1A 00 00 00 00 00 	; 00e ....6...........
	02 00 08 00 01 00 9E 0F.09 00 9C 3B 2B 00 00 00 	; 00f ...........;+...
	00 00 00 00 00 00 46 33.30 38 45 36 39 43 43 38 	; 010 ......F308E69CC8
	42 41 33 41 33 35 39 41.30 45 41 42 30 33 36 41 	; 011 BA3A359A0EAB036A
	44 45 46 36 46 44 45 44.46 44 31 44 35 38 30 30 	; 012 DEF6FDEDFD1D5800
	32 42 33 42 39 43 00 00.00 00 00 00 00 00 00 00 	; 013 2B3B9C..........
	00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 	; 014 ................
	00 00 00 00 00 00 00 36.01 00 00 1A 00 1A 00 00 	; 015 .......6........
	00 00 00 02 00 08 00 01.00 C2 0F 09 00 31 09 0D 	; 016 .............1..

Die ersten 4 Bytes 6B 34 00 00 (=13419 dez) gibt die Anzahl der Records wieder. Ein Record ist 115 Bytes lang.

Exemplarisch habe ich 3 Records mal "aufgedröselt"

Code

1A 00 00 00.00 00 02 00 08 00 01 00 52 0F 09 00 48 8E 01 00.00 00 00 00 00 00 00 00 <ID> 00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 00 36 01 00 00 1A 00
............R...H...........F2644C397E2F181C27631B6E6C4290F7C810508300018E48.................................6.....

1A.00 00 00 00 00 02 00 08 00 01 00 9A 0F 09 00 53.78 2E 00 00 00 00 00 00 00 00 00 <ID> 00 00 00 00 00.00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 00 00 00 00 36 01 00 00.1A 00
................Sx..........2DB609CA0C53553A81122BED0A37FF2D9F3585B9002E7853.................................6.....
		
1A 00 00 00 00 00 02 00 08 00 01 00 9E 0F.09 00 9C 3B 2B 00 00 00 00 00 00 00 00 00 <ID> 00 00.00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 36.01 00 00 1A 00
.................;+.........F308E69CC8BA3A359A0EAB036ADEF6FDEDFD1D58002B3B9C.................................6.....

Die ersten 12 Bytes sind immer gleich, dann folgen 4 Bytes 52 0F 09 00 (=0x90F52) welche mit der ObjectID des zugehörigen File-Items übereinstimmen.
die nächsten 4 Bytes 48 8E 01 00 (=101960) entsprechen der Dateigröße. Dann folgen 8 Nullbytes und dann der Name des *.nlo Files.

Das NLO-File ist um 425 Bytes größer als das Originalattachment.

Außer der Object-ID und der Dateigröße habe ich nichts "verwertbares" gefunden. Keine Replik-ID o.ä. Die restlichen Bytes sind entweder in jedem Record gleich, oder sowieso 00.

Gruß
Roland