Может у кого есть исходник удаления файлов методом gutmann!

А что за метод ?
Если по обычному то
DeleteFile('C:\твой_файл.txt');

Или функция erase.

Метод Гутманна - алгоритм удаления данных, основанный на многократной перезаписи соответствующей области жесткого диска. Почитать можно здесь. Вот программка реализующая данный метод. Доступны сишные сорцы, мб кто-нибудь сделает доброе дело да и переведёт?

 Исходный код я не нашел. Поэтому сделал по описанию:

Код

procedure ZeroFillDelete(FileName: string); var   fs: TFileStream;   i:  integer;   procedure RandomWrite;   var b:  byte;   begin     repeat       b := Random(256); fs.Write(b, 1);     until fs.Position + 1 >= fs.Size;   end;   procedure WritePattern(pattern: byte);   const patt: array[5..31] of dword = ($555555, $AAAAAA, $924924, $492492,         $249249, 0, $111111, $222222, $333333, $444444, $555555, $666666,         $777777, $888888, $999999, $AAAAAA, $BBBBBB, $CCCCCC, $DDDDDD,         $EEEEEE, $FFFFFF, $924924, $492492, $249249, $6DB6DB, $B6DB6D, $DB6DB6);   var d: dword;   begin     d := patt[pattern] shl 8;     repeat fs.Write(d, 3); until fs.Position + 3 >= fs.Size;   end; begin   if not FileExists(FileName) then Exit;   for i := 1 to 35 do   try     fs := TFileStream.Create(FileName, fmOpenReadWrite);     try       if (i < 5) or (i > 31) then RandomWrite       else WritePattern(i);     finally       fs.Free;     end;   except Exit; end;   DeleteFile(FileName); end;

 

Код

procedure ZeroFillDelete(FileName: string); var   fs: TFileStream;   i:  integer;   procedure RandomWrite;   var b:  byte;   begin     repeat       b := Random(256); fs.Write(b, 1);     until fs.Position + 1 >= fs.Size;   end;   procedure WritePattern(pattern: byte);   const patt: array[5..31] of dword = ($555555, $AAAAAA, $924924, $492492,         $249249, 0, $111111, $222222, $333333, $444444, $555555, $666666,         $777777, $888888, $999999, $AAAAAA, $BBBBBB, $CCCCCC, $DDDDDD,         $EEEEEE, $FFFFFF, $924924, $492492, $249249, $6DB6DB, $B6DB6D, $DB6DB6);   var d: dword;   begin     d := patt[pattern] shl 8;     repeat fs.Write(d, 3); until fs.Position + 3 >= fs.Size;   end; begin   if not FileExists(FileName) then Exit;   for i := 1 to 35 do   try     fs := TFileStream.Create(FileName, fmOpenReadWrite);     try       if (i < 5) or (i > 31) then RandomWrite       else WritePattern(i);     finally       fs.Free;     end;   except Exit; end;   DeleteFile(FileName); end;

Цитата(Snowy @  11.4.2006,  18:14 )

fs := TFileStream.Create(FileName, fmOpenWrite);

Академически верно, но только у дров винта свой взгляд на это дело.    Выражается он словом Буферизация...

Предлагаю использовать работу с файлом через хендл, созданный с флагом FILE_FLAG_WRITE_THROUGH, предотвращающим кеширование.

Вот пример процедуры, что реально пишет в файл на диске указанное число раз:

Код

procedure WipeFile(FileName:string); var  Fil:cardinal; FSize,Pass,Portion:integer; Buf:Pointer; begin   try     //create & fill wipe buffer if needed     if WipeBuffer = nil then     begin         GetMem(WipeBuffer,WipeBufferSize+2);         asm            push eax            push edi            push ecx            mov edi,[WipeBuffer]            mov ecx,WipeBufferSize+2            shr ecx,1            mov eax,$AA55;            rep stosw            pop ecx            pop edi            pop eax         end;         //Prevent 'Insert disk in drive' message box         SetErrorMode(SEM_FAILCRITICALERRORS);     end;     //find file     if not FileExists(FileName) then exit;     //wipe given file with given number of passes     for Pass := 1 to WipePasses do     begin         //Open file         //Fil := FileOpen(PChar(FileName),fmOpenWrite or fmShareDenyWrite);         Fil := CreateFile(PChar(FileName),GENERIC_WRITE,                     FILE_SHARE_WRITE,nil,                     OPEN_EXISTING,                     FILE_FLAG_WRITE_THROUGH,0);         if Fil < 0 then exit;   //INVALID_HANDLE_VALUE         //Detect size of file         FSize := FileSeek(Fil,0,2);         //on beginning         FileSeek(Fil,0,0);         //fill with buffer         while FSize<>0 do         begin            //detect size of portion             if WipeBufferSize > FSize then                 Portion := FSize             else                 Portion := WipeBufferSize;             //Detect start of buffer according to Pass             if Odd(Pass) then                 Buf := @WipeBuffer^[0] else                 Buf := @WipeBuffer^[1];             //Actual write             FileWrite(Fil,Buf^,Portion);             FSize := FSize - Portion;         end;         //flush file {?}         //close file         FileClose(Fil);     end;     DeleteFile(PChar(FileName));   except     Log('-Except on wiping file');   end; end;

Правда тут идет метод "скользящей расчёски", вместо Гутмана, но истинные ценители стандартов могут без труда это туда прикрутить.. 
 

Цитата(Snowy @  11.4.2006,  18:14 )

fs := TFileStream.Create(FileName, fmOpenWrite);

Код

procedure WipeFile(FileName:string); var  Fil:cardinal; FSize,Pass,Portion:integer; Buf:Pointer; begin   try     //create & fill wipe buffer if needed     if WipeBuffer = nil then     begin         GetMem(WipeBuffer,WipeBufferSize+2);         asm            push eax            push edi            push ecx            mov edi,[WipeBuffer]            mov ecx,WipeBufferSize+2            shr ecx,1            mov eax,$AA55;            rep stosw            pop ecx            pop edi            pop eax         end;         //Prevent 'Insert disk in drive' message box         SetErrorMode(SEM_FAILCRITICALERRORS);     end;     //find file     if not FileExists(FileName) then exit;     //wipe given file with given number of passes     for Pass := 1 to WipePasses do     begin         //Open file         //Fil := FileOpen(PChar(FileName),fmOpenWrite or fmShareDenyWrite);         Fil := CreateFile(PChar(FileName),GENERIC_WRITE,                     FILE_SHARE_WRITE,nil,                     OPEN_EXISTING,                     FILE_FLAG_WRITE_THROUGH,0);         if Fil < 0 then exit;   //INVALID_HANDLE_VALUE         //Detect size of file         FSize := FileSeek(Fil,0,2);         //on beginning         FileSeek(Fil,0,0);         //fill with buffer         while FSize<>0 do         begin            //detect size of portion             if WipeBufferSize > FSize then                 Portion := FSize             else                 Portion := WipeBufferSize;             //Detect start of buffer according to Pass             if Odd(Pass) then                 Buf := @WipeBuffer^[0] else                 Buf := @WipeBuffer^[1];             //Actual write             FileWrite(Fil,Buf^,Portion);             FSize := FSize - Portion;         end;         //flush file {?}         //close file         FileClose(Fil);     end;     DeleteFile(PChar(FileName));   except     Log('-Except on wiping file');   end; end;

вот вношу предложение.
можете потестировать, насколько возможно востановить оригинальный файл

Код

program FileErase; {$APPTYPE CONSOLE} uses   SysUtils,   Graphics,   Classes; var   BitMap: TBitmap;   FS: TFileStream;   FileName: string; begin   if ParamCount<>1 then begin     WriteLn('Ошибка! Неверное число параметров!');     WriteLn('Формат команды: FileErase FileName');     Halt(1);   end;   FileName:=ParamStr(1);   if not FileExists(FileName) then begin     WriteLn('Ошибка! Указаный файл не существует!');     Halt(2);   end;   BitMap:=TBitmap.Create;   BitMap.Width:=16;   BitMap.Height:=16;   BitMap.PixelFormat:=pfDevice;   FS:=TFileStream.Create(FileName, fmOpenWrite);   BitMap.SaveToStream(FS);   BitMap.Free;   FS.Size:=FS.Position;   FS.Free;   DeleteFile(FileName);   WriteLn('Файл '+FileName+' удален'); end.

 

Код

program FileErase; {$APPTYPE CONSOLE} uses   SysUtils,   Graphics,   Classes; var   BitMap: TBitmap;   FS: TFileStream;   FileName: string; begin   if ParamCount<>1 then begin     WriteLn('Ошибка! Неверное число параметров!');     WriteLn('Формат команды: FileErase FileName');     Halt(1);   end;   FileName:=ParamStr(1);   if not FileExists(FileName) then begin     WriteLn('Ошибка! Указаный файл не существует!');     Halt(2);   end;   BitMap:=TBitmap.Create;   BitMap.Width:=16;   BitMap.Height:=16;   BitMap.PixelFormat:=pfDevice;   FS:=TFileStream.Create(FileName, fmOpenWrite);   BitMap.SaveToStream(FS);   BitMap.Free;   FS.Size:=FS.Position;   FS.Free;   DeleteFile(FileName);   WriteLn('Файл '+FileName+' удален'); end.

Цитата(drkot @  23.6.2006,  14:35 )

Код BitMap:=TBitmap.Create;   BitMap.Width:=16;   BitMap.Height:=16;   BitMap.PixelFormat:=pfDevice;   FS:=TFileStream.Create(FileName, fmOpenWrite);   BitMap.SaveToStream(FS);   BitMap.Free;   FS.Size:=FS.Position;   FS.Free;

  

То есть, если я так понял, то при монохромном экране (pf1bit), я не смогу восстановить первые 126 символов в удаляемом таким образом файле? А теперь представим, что это был текст около мегабайта весом, и в самом начале шел список лиц, кому позволено читать и удалять данный файл, и всякая ненужная инфа, но дальше - сплошные номера счетов и пароли к ним..   
 

Цитата(drkot @  23.6.2006,  14:35 )

Код BitMap:=TBitmap.Create;   BitMap.Width:=16;   BitMap.Height:=16;   BitMap.PixelFormat:=pfDevice;   FS:=TFileStream.Create(FileName, fmOpenWrite);   BitMap.SaveToStream(FS);   BitMap.Free;   FS.Size:=FS.Position;   FS.Free;

Код

BitMap:=TBitmap.Create;   BitMap.Width:=16;   BitMap.Height:=16;   BitMap.PixelFormat:=pfDevice;   FS:=TFileStream.Create(FileName, fmOpenWrite);   BitMap.SaveToStream(FS);   BitMap.Free;   FS.Size:=FS.Position;   FS.Free;

Цитата(Mechanic @  24.6.2006,  03:22 )

первые 126 символов

Если уважаемый Mechanic более внимательно  посмотрит на представленный код надеюсь вид смайлика изменится.

Просто попробуй востановить твой файл (со счетами и паролями) удаленный при помощи этого алгоритма.

Немного о принципах заложенных в алгоритм.
 Родилося этот код в течение минут 10.
 Идея же, появилась раньше. Безсонными ночами в процессе юзания заглючивших винтов.
 Что делает алгоритм:
     - затирает некоторое количество байт в начале файла заменяя их структурой BMP;
     - размер искомого файла уменьшается до размера структуры BMP;
     - переименовывает файл (в коде не реализовано)
     - удаляется полученный файл. 

 При попытке востановления (сканирование диска на предмет точек входа) будет найден искомый файл который содержит графические данные. При этом никаких упоминаний о первоначальном размере и содержимом обнаружено не будет.
 Предположим злоумышленнику удалось получить образ удаленного файла искомого размера.
В большинстве случаев служебная информация (тип файла, параметры, структуры и тд) хранится в первом килобайте, а он как раз и затерт. (Попробуй востановить данные из архива, БД, графики и пр с затертым заголовком)

Моя оценка применимости:
  Как и говорил ранее защита далеко не стопроцентная, но скорость во много раз выше чем у предложенных 100% алгоритмов.
  Обеспечит надежную защиту от простых юзверей и coolхацкеров, и значительно затруднит работу проффесионалам (особенно если не знать точных параметров начального файла).
  Для спецслужб конечно не годится (Гутманна - там самое оно), а для рядового использования дома и на работе прокатит   
 

Цитата(Mechanic @  24.6.2006,  03:22 )

то при монохромном экране (pf1bit)

надеюсь не все так мучатся как ты   

ЗЫЖ делай дефрагментацию после удаления и никакие алгоритмы тебе не понадобятся. 

Цитата(Mechanic @  24.6.2006,  03:22 )

первые 126 символов

Цитата(Mechanic @  24.6.2006,  03:22 )

то при монохромном экране (pf1bit)

Цитата(drkot @  24.6.2006,  12:15 )

Просто попробуй востановить твой файл (со счетами и паролями) удаленный при помощи этого алгоритма.

Удачно восстановлю, просто пробежав по диску. Конечно же, заголовки FS не буду брать во внимание (разве что, чтоб исключить кластеры, занятые заведомо не теми файлами).

Цитата(drkot @  24.6.2006,  12:15 )

В большинстве случаев служебная информация (тип файла, параметры, структуры и тд) хранится в первом килобайте, а он как раз и затерт. (Попробуй востановить данные из архива, БД, графики и пр с затертым заголовком)

Цитата(Mechanic @  24.6.2006,  03:22 )

А теперь представим, что это был текст около мегабайта весом, и в самом начале шел список лиц, кому позволено читать и удалять данный файл, и всякая ненужная инфа, но дальше - сплошные номера счетов и пароли к ним..

И где в текстовике такой заголовок? Нет его..    Не случайно привел пример именно текстового файла. Кстати, файлы баз данных типа DBASE, MDF (MS SQL), etc также часто легко восстанавливаются при утере заголовка. То же можно сказать и о многих графических форматах, где не используется сжатие (типа DIB, WMF, DXF), аудио файлы (PCM WAV), тот же HTML, XML, да много еще чего можно восстановить с малыми потерями.

Вывод - метод имеет право на жизнь, но только в указанных областях:

Цитата(drkot @  24.6.2006,  12:15 )

Обеспечит надежную защиту от простых юзверей и coolхацкеров, и значительно затруднит работу проффесионалам (особенно если не знать точных параметров начального файла).   Для спецслужб конечно не годится (Гутманна - там самое оно), а для рядового использования дома и на работе прокатит

Домохозяйки only! 

Добавлено @ 12:51 

Цитата(drkot @  24.6.2006,  12:15 )

Цитата(Mechanic @  24.6.2006,  03:22 ) то при монохромном экране (pf1bit) надеюсь не все так мучатся как ты

Это чисто теоретически, самый пиковый для алгоритма вариант, я так не мучаюсь.. 

Цитата(drkot @  24.6.2006,  12:15 )

Просто попробуй востановить твой файл (со счетами и паролями) удаленный при помощи этого алгоритма.

Цитата(drkot @  24.6.2006,  12:15 )

В большинстве случаев служебная информация (тип файла, параметры, структуры и тд) хранится в первом килобайте, а он как раз и затерт. (Попробуй востановить данные из архива, БД, графики и пр с затертым заголовком)

Цитата(Mechanic @  24.6.2006,  03:22 )

А теперь представим, что это был текст около мегабайта весом, и в самом начале шел список лиц, кому позволено читать и удалять данный файл, и всякая ненужная инфа, но дальше - сплошные номера счетов и пароли к ним..

Цитата(drkot @  24.6.2006,  12:15 )

Обеспечит надежную защиту от простых юзверей и coolхацкеров, и значительно затруднит работу проффесионалам (особенно если не знать точных параметров начального файла).   Для спецслужб конечно не годится (Гутманна - там самое оно), а для рядового использования дома и на работе прокатит

Цитата(drkot @  24.6.2006,  12:15 )

Цитата(Mechanic @  24.6.2006,  03:22 ) то при монохромном экране (pf1bit) надеюсь не все так мучатся как ты

Мне не хочется с тобой спорить Mechanic .

Цитата(Mechanic @  24.6.2006,  12:46 )

Удачно восстановлю, просто пробежав по диску.

Просто слелай. Вопрос только в том, что и где ты будеш искать? Може для тебя новость что файлы редко расположены одной цепочкой.

Цитата(Mechanic @  24.6.2006,  12:46 )

И где в текстовике такой заголовок?

Я просто понадеялся, что проффесионалы как ты нехранят секретные данные в открытых текстовых файлах (HTML, XML и прочем). 

Цитата(Mechanic @  24.6.2006,  12:46 )

о многих графических форматах

плз примеры. ИМХО БМП только (если не учитавать битность и размер поверхности) все остальные так или иначе кодируются.

Цитата(Mechanic @  24.6.2006,  12:46 )

аудио файлы (PCM WAV)

Сначала "И много их у тебя?". У меня много только параметру уних хитрые и разные (8196Гц, 1-12каналов) могу удалить заголовочек и прислать тебе востанавливай.

Цитата(Mechanic @  24.6.2006,  12:46 )

файлы баз данных типа DBASE, MDF (MS SQL), etc также часто легко восстанавливаются

Не так уж и легко, хотябы структуру и последовательность полей надо знать. (Прям как в песне про поезд)

Цитата(Mechanic @  24.6.2006,  12:46 )

Домохозяйки only!

Вижу заметный прогресс в смайликах   . Но также налицо избыточная ирония объективных причин к которой не вижу. Если Вы недостаточно хорошо знакомы с процессом востановления винта после збоя то советую затереть нулевой сектор (практически безболезненая процедура для хранимых данных) и потренироваться в реанимации (и так регулярно раз в неделю в течение полугода). После такого количества востановленых винтов я лично начал относится к этому вопросу философски.

Сори. Если чем обидел. Но потеряные гигобайта невостановимых данных , начальство  способствует более серьезному отношению к проблеме сохранности информации. 

Цитата(Mechanic @  24.6.2006,  12:46 )

Удачно восстановлю, просто пробежав по диску.

Цитата(Mechanic @  24.6.2006,  12:46 )

И где в текстовике такой заголовок?

Цитата(Mechanic @  24.6.2006,  12:46 )

о многих графических форматах

Цитата(Mechanic @  24.6.2006,  12:46 )

аудио файлы (PCM WAV)

Цитата(Mechanic @  24.6.2006,  12:46 )

файлы баз данных типа DBASE, MDF (MS SQL), etc также часто легко восстанавливаются

Цитата(Mechanic @  24.6.2006,  12:46 )

Домохозяйки only!

Цитата(drkot @  24.6.2006,  13:31 )

Просто слелай. Вопрос только в том, что и где ты будеш искать? Може для тебя новость что файлы редко расположены одной цепочкой.

Если восстанавливать "на арапа" "всё, что возможно восстановить", то да, не зная, что ищешь, тяжко будет. Но обычно тот, кто ищет что-то, нарочно кем-то скрытое, знает, что именно он ищет.
А насчет цепочки, да, в курсе. Знаю, чем отличаются FS CP-M, TR-DOS от FS FATXX.  Но если следовать совету про регулярные дефраги, то сложность с сегментированием, вроде как, перестаёт быть особой сложностью.. 

Цитата(drkot @  24.6.2006,  13:31 )

Я просто понадеялся, что проффесионалы как ты нехранят секретные данные в открытых текстовых файлах (HTML, XML и прочем).

Это параноики хранят ярлыки не в LNK, но в собственных криптованных форматах  , профессионалы же обычно пользуются теми форматами, которые использует софт, с которым они работают. А львиная доля бизнес, и промышленного софта как раз использует универсальные форматы, перекладывая такие аспекты, как безопасность, на ОСь (EFS, etc), и спец-средств (крипто-контейнеры, файловые шифрователи, и т.д.).
Не стоит забывать и об организационных способах обеспечения информационной безопасности, когда безопасность данных обеспечивается ограничением физического доступа к носителям и каналам передачи информации, но не программно-аппаратными средствами. В случае компрометации такой вот защиты как раз и придётся иметь дело с открытыми данными (пускай даже и уничтоженными аварийным софтом в последний момент).

Цитата(drkot @  24.6.2006,  13:31 )

плз примеры. ИМХО БМП только (если не учитавать битность и размер поверхности) все остальные так или иначе кодируются.

Просто посмотри внутрь перечисленных мною DXF, TIFF (not compressed), WMF, EMF. Можно также посмотреть на формат PDF, где стримы идут последовательно, каждый отдельно.
К тому же, методы компрессии тоже в этом смысле отличаются. Например, всё, что использует словари (Хаффман, LZW, etc) будет тяжело поднять, но вот что касается RLE-подобных систем, то тут всё намного проще.

Кстати, может открою новость , но видео-данные в том же DIVX, MPEG, etc элементарно читаются без RIFF-заголовков. Можно попробовать даже очень распространенным "бытовым" софтом это проделать (типа Virtual Dub). Хотя лучше всё-таки использовать специализированный (который однозначно есть у тех, кто будет ковыряться в потёртом винте  ). В работе с видео, если речь идет не о любительской порнушке, но о системах видеонаблюдения, видеозахвата, то всё упрощается до безобразия - в спецификации аппаратуры (настройках софта) находим данные о предпологаемом формате видеопотока, конструируем нужные заголовки, возможно их фиксим на глобальные поля (типа длины потока), и можем смотреть в стандартном медиаплеере. (Можно не оспаривать, частенько это делал лично).

Цитата(drkot @  24.6.2006,  13:31 )

Сначала "И много их у тебя?". У меня много только параметру уних хитрые и разные (8196Гц, 1-12каналов) могу удалить заголовочек и прислать тебе востанавливай

Есть у меня машинка, в которую воткнута железка, которая пишет очень-даже сенситивные данные с многоканального адаптера именно в PCM формате.. И честно говоря, мне, даже если я подхвачу паранойу, не придёт в голову перепатчивать дрова этой железки, чтоб паковали / криптовали.. А много ли? Десятки GB.   
Кстати, аудио-данные легко распознать даже в сплошном массиве, не сильно сложным анализом, тем более, если речь идет о речевой информации. (Не думаю, что прятать и восстанавливать будут музыку, разве только в шоу-бизнесе ).

Цитата(drkot @  24.6.2006,  13:31 )

Цитата(Mechanic @  24.6.2006,  12:46 ) файлы баз данных типа DBASE, MDF (MS SQL), etc также часто легко восстанавливаются Не так уж и легко, хотябы структуру и последовательность полей надо знать. (Прям как в песне про поезд)

Предположим, что структура полей привязана к оболочке (клиентский слой, или сервер приложений (бизнес-логики)), тогда при уничтожении данных на сервере, на рабочих станциях обычно остается клиентское ПО, по которому легко восстановить структуру БД. Если же софт стандартный, то вообще сложности с восстановлением структуры данных не возникнет.
Даже анализ БД с разрушенной логической целостностью может дать очень много полезной информации. Текстовые поля можно извлечь в структурированные таблицы, а определить логическую семантику такого списка может сделать мало-мальски подкованный в данной сфере аналитик.

Цитата(drkot @  24.6.2006,  13:31 )

Вижу заметный прогресс в смайликах   . Но также налицо избыточная ирония объективных причин к которой не вижу. Если Вы недостаточно хорошо знакомы с процессом востановления винта после збоя то советую затереть нулевой сектор (практически безболезненая процедура для хранимых данных) и потренироваться в реанимации (и так регулярно раз в неделю в течение полугода). После такого количества востановленых винтов я лично начал относится к этому вопросу философски.

Всё ясно. И ирония моя перестает казаться избыточной, если разобраться, что идет она от комичности самой ситуации..  Ничего личного, никаких обид, или чего-нить такого, просто здесь затеяли флейм сокрываторы информации с одной стороны, и её восстановители с другой. 
Может быть я и не очень часто восстанавливаю информацию после сбоя винтов, но вот удалять (wipe'ить) приходится частенько, а также криптовать, и всячески боронить эту самую информацию..

А при написании алгоритма с битмапом явно на подсознательном уровне сработала мысль, что уничтоженную таким образом инфу придется потом восстанавливать?  И метод как раз позволяет обойтись "малой кровью" (без применения сложного оборудования для анализа остаточной намагниченности, эл. микроскопов, и т.д.) именно при восстановлении..   

Цитата(drkot @  24.6.2006,  13:31 )

Просто слелай. Вопрос только в том, что и где ты будеш искать? Може для тебя новость что файлы редко расположены одной цепочкой.

Цитата(drkot @  24.6.2006,  13:31 )

Я просто понадеялся, что проффесионалы как ты нехранят секретные данные в открытых текстовых файлах (HTML, XML и прочем).

Цитата(drkot @  24.6.2006,  13:31 )

плз примеры. ИМХО БМП только (если не учитавать битность и размер поверхности) все остальные так или иначе кодируются.

Цитата(drkot @  24.6.2006,  13:31 )

Сначала "И много их у тебя?". У меня много только параметру уних хитрые и разные (8196Гц, 1-12каналов) могу удалить заголовочек и прислать тебе востанавливай

Цитата(drkot @  24.6.2006,  13:31 )

Цитата(Mechanic @  24.6.2006,  12:46 ) файлы баз данных типа DBASE, MDF (MS SQL), etc также часто легко восстанавливаются Не так уж и легко, хотябы структуру и последовательность полей надо знать. (Прям как в песне про поезд)

Цитата(drkot @  24.6.2006,  13:31 )

Вижу заметный прогресс в смайликах   . Но также налицо избыточная ирония объективных причин к которой не вижу. Если Вы недостаточно хорошо знакомы с процессом востановления винта после збоя то советую затереть нулевой сектор (практически безболезненая процедура для хранимых данных) и потренироваться в реанимации (и так регулярно раз в неделю в течение полугода). После такого количества востановленых винтов я лично начал относится к этому вопросу философски.