Wat is het patroon/algoritme in deze bestandsnamen?

[radicalEMT]

Ik ben bezig met het migreren van een beeldenarchief. De metadata van de beelden zitten in een SQL database, de daadwerkelijke beelden/bestanden staan op een fileshare.
Als er bij een onderzoek meerdere beelden zijn gemaakt plaatst het systeem deze in een .tar bestand (ongecomprimeerd).

Hieronder een schermafbeelding van de metadata en de .tar bestanden met inhoud.



De naam van het .tar bestand is eenvoudig te vinden in de database (544769087), maar de naam van de bestanden 544701102.dcm etc. niet. Het eerste gedeelte 5447 is duidelijk, maar waar komt de 01102 etc vandaan?

Ziet iemand het patroon?

[MAX3400]

Het enige wat ik me kan voorstellen, maar aanname, dat je meerdere machines hebt staan die die bestanden opleveren en dat dus de correlatie tussen TAR en inhoud niet (meer) overeenkomt.

Simpele gedachtegang: 2 machines leveren allebei 001.tar aan maar in elke tar zitten andere bestanden. Als je de tar-naam als non-indexed waarde gebruikt, kan ik me voorstellen dat de rest van de records niet mag/kan worden geupdate.

Je zou het kunnen testen met een nieuwe tar (2x dezelfde naam) maar beiden met een ander bestand erin.

[nescafe]

De kolommen "offset" en "size" zouden al een hint moeten geven. Deze geven de relatieve positie van de bestanden in de tar aan. Met een willekeurige binary stream reader zou je deze files er zo gerelateerd aan de rows in de table uit kunnen halen.

[radicalEMT]

Dank voor de suggesties. Inderdaad lukt het om de bestanden uit te pakken aan de hand van de offset en size, echter ben ik benieuwd hoe die naam nou opgebouwd is van de objecten. Er moet een logica inzitten, ik zie het echter nog niet....

[nescafe]

Ah.. dan begrijp ik de vraag niet helemaal. Je wilt de beelden migreren, dit lukt niet met het untarren van de file (dan mis je de relatie tussen SQL-record en file) maar wel met het uitlezen van de tar als binary stream (waarbij je de relatie kunt leggen o.b.v. offset).

Dan kun je nog een relatie leggen tussen de binaire data en de bestandsnaam door in de 1e 100 bytes van het block van 512 bytes voor de offset te kijken (wiki).

Een verklaring voor de gebruikte bestandsnamen om hiermee gegevens te kunnen herleiden lijkt me niet nodig. Blijft over dat je een verklaring zou willen voor het "waarom" van de gebruikte bestandsnamen en daar kan ik eigenlijk alleen naar gissen.. wellicht gerelateerd aan de tijd in een bepaalde precisie?

Kun je aangeven waarom de bestandsnaam van belang is?

[Stoelpoot]

nescafe schreef op donderdag 7 juni 2018 @ 09:46:
Kun je aangeven waarom de bestandsnaam van belang is?

Dit inderdaad. De bestandsnaam kan je aanpassen op elke manier die jij wilt, je bent toch aan het migreren. Je kan nu een bestand aan een record koppelen, dat is in principe voldoende, lijkt mij?

[CCJJVV]

Het verschil tussen ID3 en het getal in Name is 14 maal 95631152, twee maal 956311523 en eenmaal 95631151. Dat extra verschil kan op werkelijk alles gebaseerd zijn, inhoud, tijd, size, offset een combinatie van meerdere. Verder snap ik net als de andere niet waarom je dit zou willen weten.

[radicalEMT]

Ha, de reden waarom de bestandsnaam van belang is, is gewoon nieuwsgierigheid. Het migreren lukt zeker, ook zonder dat we de namen weten.
Het zit mij gewoon dwars dat ik de logica niet inzie van de naamgeving , misschien dat een ander dat wel ziet!

[Stoelpoot]

radicalEMT schreef op donderdag 7 juni 2018 @ 10:36:
Ha, de reden waarom de bestandsnaam van belang is, is gewoon nieuwsgierigheid. Het migreren lukt zeker, ook zonder dat we de namen weten.
Het zit mij gewoon dwars dat ik de logica niet inzie van de naamgeving , misschien dat een ander dat wel ziet!

Ik bijna zeggen dat het gewoon willekeurig gegenereerd is. De bestandsnamen zijn niet nodig, dus de enige logica erachter moet er voor zorgen dat de namen uniek blijven.

[Stinu]

Misschien dat het schrijven naar de TAR via een apart process/thread loopt.
En dat deze ook met een unique ID werkt.

En omdat het toevoegen in de database & schrijven naar TAR niet even snel / niet zelfde volgorde (door mogelijk priority) loopt.
Kom je mogelijk met kleine verschillen tussen de ID's zoals @CCJJVV aan geeft.

Deze zitten misschien nog ergens anders in de database opgeslagen?

[radicalEMT]

Deze zitten misschien nog ergens anders in de database opgeslagen?

Overal al gekeken, is nergens in de database te vinden. Lijkt er inderdaad op dat een apart proces hier zorg voor draagt.

[elhopo]

Lijkt een soort van timestamp te zijn. Waarschijnlijk zal een ontwikkelaar om unieke namen te genereren het laatste deel van een timestamp uit de een of andere systeemtimer hebben gehaald. Als je systeem niet al te snel is zal dit ws. wel goed gaan. File toevoegen aan een tar zal dan zo'n 9 a 10 milliseconden duren? Dus naam is (5447 + system.gettimeinmillis().toString.right(5)) ofzo. Of de uptime van het systeem in microseconden ofzo en dan de laatste 5 cijfers.

[Kontsnorretje]

Volgens mij is het gewoon een volg nummer. Als ik kijk naar ID3, en de bestandsnamen in de Tar, slaan deze, op de eerste 2 na, net zoveel IDs over.

Hoe dit zich tot elkaar verhoudt is dan weer een andere vraag.

[HuHu]

Voor zover ik weet zit er geen logica in DICOM bestandsnamen. Gewoon unieke nummers. Voor de volgorde en andere informatie moet je de DICOM tags uitlezen.

[drm]

Het patroon voor de tar bestanden is helder. Ze eindigen altijd op 69087.

Je zal toch met meer data moeten komen om hier een patroon in te kunnen ontdekken.