Привет!

RedHair wrote:
> Почему бы этому не быть? Представьте себе ситуацию — вы создаете большой (100кб, к примеру) файл, куда пишете некие данные. Вполне возможна ситуация, когда файл фрагментируется и данные разорвутся — на физическом уровне.

Ну 100 Кб — это не большой, а маленький файл. Большой — это 10 Гбайт
. Но дело, конечно, не в этом.

> Далее, если открыть диск (не файл), и начать в нем искать кусок своих данных, вы вполне его не найдете, ведь первая треть его находится в одном кластере, а вторая — совсем в другом, не идущем непосредственно за первым.

Вот здесь твоя ошибка (точнее, непонимание) и заключается.
Работа с файлами идет на разных уровнях.
A.На нашем уровне (обычное Win32 приложение) файл — это
последовательность байт определенного размера. Все. Больше ничего. Как
они там хранятся — НАС ВООБЩЕ НЕ КАСАЕТСЯ. Хоть в кластерах, хоть с
помощью духа святого. Мы этого не знаем, не хотим знать и не имеем права
знать. В любом случае, для нас файл непрерывный. Других НЕ БЫВАЕТ.

B.А на уровне ниже можно обсуждать его ФИЗИЧЕСКОЕ размещение. Если HDD
или FDD — в кластерах. Если в сети — сетевой редиректор чего-то там
делает и откуда-то эти байты файла берет и куда-то записывает. Если он
от MS — одним способом. Если от Netware — совсем по-другому. Если файл
на CDROM — там тоже по-своему. Более того, файл может в действительности
находиться на ftp сервере (FtpGetFile) и для доступа к нему используется
ftp протокол, а где сам файл — о том только хозяин ftp сервера (который
вообще может быть машиной на Unix) знает.

C.А еще ниже — область электроники/оптики/магнитооптики. Там тебе
объяснят, что такое 0 и что такое 1 на винчестере, как реально
(намагниченности, интенсивности и т.п.) хранятся данные на носители. Это
уже физиков епархия.

Сейчас ты на уровне A. Поэтому уровни B и C тебя не касаются вообще.
Драйвер файловой системы или редиректор сети (они на уровне B) сделают
все, что надо, чтобы для тебя файл казался непрерывным.

А вот если сама начнешь писать драйвер файловой системы — тогда да,
тогда тебе придется думать о том, в каких кластерах (а может, и не
кластерах размещать данные и как сделать так, чтобы на уровне A их
видели непрерывными файлами. Но про уровень C даже здесь не надо думать.

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

Я упростил. В действительности уровень B состоит из ряда подуровней
(драйвер файловой системы, драйвер томов (кстати, он позволяет (о ужас!
хранить файл не только фрагментированным на диске, но хранить его
куски на разных дисках вообще), драйвер физического диска. И каждый из
этих подуровней ничего не знает о подуровне ниже и не хочет знать.

> Признаю себя ослом!!!

Не надо так. Все могут ошибаться

> Вопрос, тем не менее, остается достаточно интересным, с познавательной точки зрения!!!

А вот это уже серьезный вопрос.
В действительности все что я сказал, верно с одной поправкой. А именно —
фрагментирование может замедлить работу с файлом. Для меня он
непрерывный, так, но реально-то нет. Чем больше движений головки, тем
медленнее работа.
О дефрагментации см. MSDN, Defragmenting Files. Но прежде надо хорошо
понять, как файлы хранятся на томах NTFS, что такое VCN-LCN и т.д.

--
With best regards,
Pavel Dvorkin