Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Система";
Текущий архив: 2003.07.24;
Скачать: [xml.tar.bz2];

Вниз

Wipe файла...   Найти похожие ветки 

 
Deus   (2003-05-15 14:26) [0]

Всем привет!

Как сделать сабж?
Я так подозреваю, что если просто открыть файл и записать туда много нуликов, то не факт, что запись пойдёт именно в те сектора, где располагался исходный файл.

Но различные вайперы(нортоновские и пгпешные) утверждают, что 100% затирают именно данные указанного файла. Как они это делают?


 
Anatoly Podgoretsky   (2003-05-15 14:29) [1]

Пойдет туда куда надо, по крайней мере в общем случае.


 
Digitman   (2003-05-15 14:42) [2]

см. OpenFile, CreateFileMapping, MapViewOfFile, Flush-ф-ции и т.п.


 
Deus   (2003-05-15 15:10) [3]

2Anatoly Podgoretsky:
Обычно, при необходимости затереть данные, нужна 100% гарантия. А частные случаи этот процент уменьшают, что нежелательно.
Например: файл X расположен в секторах 1,3,4. В секторе 2 - файл Y. Через какое-то время файл Y стёрли.
Если после этого я начну писать в файл X, то ведь запись будет идти в сектора 1-2-3, так? Должен быть способ работать на более низком уровне! Ведь дефрагментаторы работают именно с секторами...

2Digitman:
Хорошая мысль...


 
Morfein   (2003-05-15 15:30) [4]

Чё значит пойдёт не туда? А куда пойдёт запись? В соседние файлы? :) А способ, предложенный Digitman"ом, ни чем не отличается от того, что ты сам сказал в начале... только что с file mapping"ом быстрее...


 
Deus   (2003-05-15 16:08) [5]

2Morfein:
Неа, не в соседние файлы. В освободившееся пространство. См. пример в моём ответе Anatoly Podgoretsky.


 
Digitman   (2003-05-15 16:10) [6]


> Если после этого я начну писать в файл X, то ведь запись
> будет идти в сектора 1-2-3, так?


Не так. Точнее, не всегда так. И работа с файловой системой на носителе идет прежде всего на уровне кластеров, объединяющих последовательно расположенные логические сектора в группы установленного при инициализации файловой системы размера. Дефрагментация - не исключение.

Вот смотри.
Пусть размер кластера - 8 секторов (0.5 кб * 8 = 4кб)

Существуют:

Файл X (10 кб) - кластеры 1 -> 3 -> 5 (3 * 4кб = 12кб - занято на диске)
Файл Y (9 кб)- кластеры 2 -> 4 -> 6 (3 * 4кб = 12кб - занято на диске)

Цепочка кластеров 7, 8, 9, 10 - свободна.
Файл Y удален. Цепочка из кластеров 2, 4, 6 помечена как свободная

Теперь - варианты возможных развитий событий:

1. Открыли файл X, модифицировали его содержимое без изменения размера.
Закрываем файл. Результирующие те же самые 9 кб обновят (при необходимости) каждый из кластеров занятой файлом цепочки 1, 3, 5

2. Открыли файл X, модифицировали его так, что он стал "урезанным" на 1 кб - всего 9 - 1 = 8 кб.
Закрываем файл. Эти результируюшие 8 кб (2 * 4кб) "по месту" физического размещения обновят (при необходимости) содержимое первых 2-х кластеров (1, 3) из ранее занимаемой файлом Х цепочки (1, 3, 5). Кластер 5 будет помечен как свободный ("огрызок" бывшего конца файла Х до модификации).

3. Открыли файл X, модифицировали его так, что он "вырос" на 5 кб - всего 9 + 5 = 14 кб.
Закрываем файл. Первые результируюшие 12 кб (3 * 4кб) "по месту" физического размещения обновят (при необходимости) содержимое 3-х кластеров (1, 3, 5) из ранее занимаемой файлом Х цепочки (1, 3, 5). Последние 2 кб будут записаны в кластер 2, который будет помечен как "занятый". В результате новое содержимое файла X займет цепочку кластеров 1, 3, 5, 2, а цепочка 4, 6 так и осталась свободной (со старым "огрызком" содержимого бывшего файла Y)

4. работа оптимизатора - см.вар-т 3-й, но результат будет записан в кластеры 7,8,9,10, а цепочка 1, 3, 5 освобождена и содержит прежний образ файла (до модификации)


 
Morfein   (2003-05-15 16:33) [7]

>> Deus
>> Неа, не в соседние файлы. В освободившееся пространство.

Даже если туда что-то и будет записано, значит система считает, что там лежит файл... и он там и лежит, если нет ошибки FAT...

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

Потому бери в руки функции MAPPING"a и не забивай голову.


 
Deus   (2003-05-15 16:38) [8]

Digitman, большое спасибо за подробное объяснение!

Несколько вопросов:
Правильно я понимаю, вариант 4 будет только в случае, если я пишу в файл блоками, т.е. на момент записи известен размер, а при побайтной записи будет вариант 3?
Вариант 4 будет только при превышении размера файла? Если файл раскидан по разным кластерам в конце диска, а в начале диска освободилось место, то если я запишу _точно то же_ кол-во байт, то не закинет ли оптимизатор их в начало?

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


 
Morfein   (2003-05-15 16:50) [9]

Deus... "4. работа оптимизатора" © Digitman
Тов. Digitman рассказал тебе, как происходит работа с файлами на физическом уровне... и некоторые частные случаи при этом... совершенно не важно, КАК ты будешь писать в файл, потому что твоя "побайтная запись" - это те же блоки, но размером в один байт.

Куда бы не забросил оптимизатор кластеры твоего сверхсекретного файла, ОС всегда будет знать, где они находятся, и при записи в файл перезапишутся именно ЭТИ кластеры, а не какое-то там пустое пространство между ними.


 
Anatoly Podgoretsky   (2003-05-15 16:55) [10]

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




 
Deus   (2003-05-15 17:25) [11]

"Новые кластеры распределяются при расширении файла, при прописывании его нулями это не произойдет"
Вот в этом я и хотел убедиться :))

Всем спасибо!



Страницы: 1 вся ветка

Форум: "Система";
Текущий архив: 2003.07.24;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.48 MB
Время: 0.008 c
14-78106
Shiza
2003-07-08 11:19
2003.07.24
Как работать с MSDN


3-77764
RAHS
2003-06-28 14:41
2003.07.24
Нечеткое сравнение полей


3-77787
Bless
2003-06-27 16:47
2003.07.24
Параметры с одинаковыми именами


1-77922
Сергей Ч
2003-07-10 14:34
2003.07.24
Установил Delphi7


3-77793
Empleado
2003-07-01 16:38
2003.07.24
ADO и Treading Model (в Мидасе)





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский