Bestand per ongeluk overschreven op vfat mount

[Confusion]

Ik heb net een bestand verwijderd dat ik liever had willen houden. Ik heb met 'recover' geprobeerd de inode terug te krijgen, maar die was nergens meer te bekennen. Goed, ik grijp naar mijn backup (op een andere schijf, wegens omstandigheden een vfat mount) en tik "tar -czf ". Toen gingen er een paar alarmbellen rinkelen, maar helaas, het kwaad was al geschied: de backup was overschreven. Belangrijkste les van vandaag: altijd eerst je backup kopieren of zorgen dat je niet zo duf bent als ik was vandaag.

Anyway, ik heb op zich nog een backup van een week geleden, maar het betreffende bestand is inmiddels gewijzigd en ik zou liever de versie uit de backup van gisteren gebruiken. Nu vraag ik mij af of iemand weet of ik het bestand op die vfat partitie nog kan redden?

[ Voor 3% gewijzigd door Confusion op 13-11-2003 00:41 ]

[Buffy]

Vreemde tar heb jij. De mijne zegt altijd dat hij een laffaard is en geen bestaande tar-files durft te overschrijven (altijd weer een pffeeeh moment ).

_{edit: vreemd, tar overschrijft hier ook gewoon, zou toch zweren dat....}

Zolang je niet naar de vfat schrijf hebt geschreven (nieuwe tar file 0 bytes?) zou je met een disk-editor opzoek kunnen gaan naar het eerste block van de oude tar-gzip-file en dat block en alle volgende blocken naar een bestand (op een andere schrijf) saven tot je een bestand van minstens de zelfde grote hebt.

Als je geluk hebt en de vfat schrijf niet al te gefragmenteerd was dan kan tar je bestand er ongeschonde uit halen.
Aangezien de tar-archive gezipt is, is het helaas alles of niets.

[ Voor 9% gewijzigd door Buffy op 13-11-2003 03:17 ]

[Confusion]

Dawns_sister schreef op 13 november 2003 @ 01:55:
Zolang je niet naar de vfat schrijf hebt geschreven (nieuwe tar file 0 bytes?)

Nee, 45 bytes.

zou je met een disk-editor opzoek kunnen gaan naar het eerste block van de oude tar-gzip-file en dat block en alle volgende blocken naar een bestand (op een andere schrijf) saven tot je een bestand van minstens de zelfde grote hebt.

Twee problemen: ik weet niet hoe het eerste blok van een tgz bestand eruit ziet (misschien is het standaard denk ik nu; eens zoeken...) en ik weet niet hoe groot het bestand was (maar misschien heeft een tgz ook een standaard afsluiter?). Bovendien heb ik waarschijnlijk het begin domweg overschreven, daarbij misschien al relevante informatie vernielende...

* Confusion gaat maar eens wat moeite doen die vfat toch naar ext2 om te zetten en dan de backup bestanden 444 te chmodden

[ Voor 7% gewijzigd door Confusion op 13-11-2003 09:19 ]

[Buffy]

Confusion schreef op 13 november 2003 @ 09:18:
[...]

Nee, 45 bytes.

Slik, hopelijk heeft tar niet de zelfde begin block gebruikt. Ik heb even een testje gedaan en het lijkt er op dat eerst het bestand wordt weggegooid en daarna een nieuwbestand wordt aangemaakt op een adere locatie (dus op een andere cluster).

[...]

Twee problemen: ik weet niet hoe het eerste blok van een tgz bestand eruit ziet (misschien is het standaard denk ik nu; eens zoeken...) en ik weet niet hoe groot het bestand was (maar misschien heeft een tgz ook een standaard afsluiter?). Bovendien heb ik waarschijnlijk het begin domweg overschreven, daarbij misschien al relevante informatie vernielende...

Een tgz is gewoon een een gezipte tar archive. Je zult dus op zoek moeten gaan naar het magic nummer van gzip (IF 8B 08 als ik het goed heb).
Je hoeft alleen maar de eerste drie bytes van iedere cluster te controleren en als je een match hebt die cluster een bv 2 keer zoveel opvolgende clusters als het als het bestand groot was save naar een bestand en dan met tar ztvf controleeren of het leesbaar is en het gezochte bestand is.

Grootte van een cluster kan je vinden in de eerste sector van je partitie. Op offset 0B-0C staat het aantal bytes per sector (512 ) en 0D bevat het aantal sectors per cluster. De alignment van de data clusters is afhankelijk van de FAT grootte en verborgen sectors. Het makkelijkste is om op zoek te gaan naar de root-directory cluster, even zoeken naar een naam (hoofdletters zonder punt) van een bestand in de root directory. De cluster begint dan bij de eerste naam.

[Confusion]

Dawns_sister schreef op 13 november 2003 @ 16:27:
Slik, hopelijk heeft tar niet de zelfde begin block gebruikt. Ik heb even een testje gedaan en het lijkt er op dat eerst het bestand wordt weggegooid en daarna een nieuwbestand wordt aangemaakt op een adere locatie (dus op een andere cluster).

Tjah, er was niet zo gek veel ruimte vrij op de betreffende schijf, dus de kans dat dezelfde plaats gebruikt is, of een plaats die onderdeel van het vorige bestand was, is redelijk groot

Een tgz is gewoon een een gezipte tar archive. Je zult dus op zoek moeten gaan naar het magic nummer van gzip (IF 8B 08 als ik het goed heb).
Je hoeft alleen maar de eerste drie bytes van iedere cluster te controleren en als je een match hebt die cluster een bv 2 keer zoveel opvolgende clusters als het als het bestand groot was save naar een bestand en dan met tar ztvf controleeren of het leesbaar is en het gezochte bestand is.

Ik weet alleen ook niet hoe groot het bestand was.

Grootte van een cluster kan je vinden in de eerste sector van je partitie. Op offset 0B-0C staat het aantal bytes per sector (512 ) en 0D bevat het aantal sectors per cluster. De alignment van de data clusters is afhankelijk van de FAT grootte en verborgen sectors. Het makkelijkste is om op zoek te gaan naar de root-directory cluster, even zoeken naar een naam (hoofdletters zonder punt) van een bestand in de root directory. De cluster begint dan bij de eerste naam.

Dank je voor de informatie. Het is me helaas niet gelukt om het bestand terug te vinden; er staan nog veel meer .tgz op die schijf en ik zag door de bomen het bos niet. Bovendien: een bestand van waarschijnlijk 50-80 MB, op een schijf waar nog pakweg 500 MB vrij is, dan is de kans vrij groot dat de nieuwe tgz. op een cluster is begonnen die tot het oorspronkelijke bestand behoorde. Ik heb voorlopig nog geen ernstige schade ondervonden van het kwijtraken van dit bestand (de ergste schade is dat ik alle mail van 24/10 tot 12/11 kwijt ben; iets waar ik misschien nog een probleem van ga ondervinden, maar dat zien we dan wel ).