Учебное пособие: Файловая система

UINT GetSystemDirectory(lpszSysPath, cbSysPath);

Интересно, что Windows не предоставляет функции для получения текущего каталога — для этого надо использовать либо функции стандартной библиотеки, либо можно узнать полный путь к выполняемому файлу, а из него выделить путь (в некоторых случаях даже важнее знать именно каталог, в котором находится исполняемый модуль, чем текущий):

Int GetModuleFileName(hInstance, lpszFileName, cbFileName);

Еще пара функций помогает создавать временные файлы. Функция GetTempDrive возвращает букву, обозначающую диск, используемый для хранения временных файлов (при этом параметр функции chDriveLetter не используется). При этом предполагается, что для хранения временных файлов используется первый жесткий диск (обычно C), а если он не существует, то текущий диск. Вторая функция — GetTempFileName помогает построить уникальное имя временного файла, при этом она использует либо переменную окружения TEMP, либо, если она не определена, то корневой каталог указанного тома, либо, если он не задан, корневой каталог первого жесткого диска (обычно C).

BYTE GetTempDrive(chDriveLetter);

Int GetTempFileName(chDriveLetter, lpszPrefixString, uUnique, lpszTempFileName);

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

Функция SetHandleCount позволяет изменить максимально допустимое число одновременно открываемых файлов одним приложением. По умолчанию одно приложение может открыть до 20 файлов сразу.

UINT SetHandleCount(cHandles);

Последняя функция возвращает информацию о типе дискового устройства. К сожалению эта информация крайне скудна — Windows распознает только три вида дисковых устройств: фиксированные (DRIVE_FIXED), сменные (DRIVE_REMOVABLE) и удаленные (DRIVE_REMOTE):

UINT GetDriveType(nDriveNumber);

Параметр nDriveNumber задает номер диска: устройство “A” имеет номер 0, “C” — 2 и так далее. Возвращаемое функцией значение тип диска (DRIVE_FIXED, DRIVE_REMOVABLE, DRIVE_REMOTE), либо, в случае ошибки, 0.

Работа с файлами, каталогами и томами в Win32 API

Средства для работы с файлами в Win32 API существенно отличаются от средств в Windows API. Одна из самых существенных, с точки зрения разработчика, особенностей — использование длинных имен файлов. Так для имени файла и расширения система отводит 255 символов. Это значит, что использование каких–либо буферов фиксированного размера для хранения полных имен файлов недопустимо! Так как полное имя содержит путь, часто насчитывающий добрый десяток вложенных каталогов, а их имена могут быть длиной до 255 символов каждый, да еще само имя файла, то определить достаточный размер такого буфера просто не представляется возможным.

Конечно, теоретически можно резервировать по 5–10 килобайт под каждое имя, надеясь, что использовать столь длинные пути со столь длинными именами никто не будет. Но это дело чисто вероятностное — пока имена файлов и каталогов приходилось хотя–бы иногда набирать руками, очень длинных путей никто и не делал, но в современных системах интерфейс разработан таким образом, что набирать имя файла или каталога приходится обычно лишь однажды — при его создании и при этом набирается только имя, а не полный путь. Это до определенной степени провоцирует на применение очень длинных имен.

Для корректной работы с длинными именами файлов надо сначала определить размер буфера, узнав длину имени, затем динамически выделить пространство, и только потом получить нужное имя. При этом надо учесть, что приложения Win32 могут быть скомпилированы для использования UNICODE, тогда каждый символ будет занимать не один байт, а два, что автоматически удваивает требуемый размер буфера.

Иногда возможно использование так называемых коротких имен вместо длинных. Дело в том, что в 32х разрядной системе возможен запуск 16ти разрядных приложений Windows и задач MS–DOS, которые, естественно, не могут работать с длинными именами. Для того, что бы старые приложения могли иметь доступ ко всем файлам, система автоматически генерирует так называемые короткие имена, подчиняющиеся соглашениям MS–DOS. Все 16ти разрядные приложения Windows и все задачи MS–DOS имеют дело с этими короткими именами. В Win32 API предусмотрены специальные функции (GetShortPathName и GetFullPathName) для получения короткого имени из длинного и наоборот. Однако надо иметь в виду, что этот механизм все–таки не гарантирует корректную работу старых приложений — полная длина пути (даже составленного из коротких имен) может превысить 144 символа, так как число вложенных подкаталогов может оказаться значительным. При этом 32х разрядная система (Windows–95 или Windows NT) будет работать с такими глубоко запрятанными файлами совершенно спокойно, но при попытке получить доступ к этим файлам средствами MS–DOS или использовать их старыми 16ти разрядными приложениями Windows возможно возникновение ошибок. Возможно, но не обязательно — смотря по тому, какие пути используются: абсолютные (длина может превышать 144 символа), или относительные (как правило их длина существенно меньше).

DWORD GetFullPathName(lpszFile, cchPath, lpszLongPath, plpszFileNamePart);

DWORD GetShortPathName(lpszLongPath, lpszShortPath, cchBuffer);

Функция GetFullPathName возвращает полное, включая путь, длинное имя файла, заданного параметром lpszFile. Если указанное имя не содержит пути, то предполагается, что файл находится в текущем каталоге. Функция GetShortPathName выполняет обратную задачу — она сообщает короткое имя файла, заданного его длинным именем.

Другая проблема — использование пробелов в именах файлов. Часто при анализе командных строк предполагается, что пробел отделяет один компонент командной строки от другого. Теперь пробел может находиться и внутри имени файла, содержащегося в этой командной строке. В таких случаях принято заключать имя файла в двойные кавычки (этот символ запрещено использовать в самих именах). А раз так, то во все средства разбора командной строки надо включать специальный анализ на выделение имен файлов, заключенных в кавычки (либо не заключенных, если в имени нет пробелов). Больше всего ошибок возникает при переносе старых приложений в Win32. Многие солидные программисты просто не замечали, что какая–то хорошо отлаженная библиотечная функция, служившая много лет им верой и правдой, вдруг даст ошибку, наткнувшись на пробел в имени файла. А поймать все такие ошибки в процессе отладки очень трудно. Такие ошибки проскакивали незамеченными во время отладки в хорошие, коммерческие продукты. Так, например, очень хороший и надежный компилятор Watcom C/C++ 10.5 содержит неожиданно много таких ошибок, причем как в библиотеках времени выполнения, так и в самой среде.

Еще один нюанс, правда сравнительно небольшой, связан с тем, что символ “.” (точка) может встречаться не только для отделения имени от расширения, но также и в самом имени, причем неоднократно. В таких случаях под расширением подразумевается часть имени, отделенная самой правой точкой. Эта особенность сравнительно редко приводит к ошибкам, так как при разборе имени его обычно анализируют справа налево[0] .

Помимо этого следует учесть, что в именах файлов могут встречаться две косые черты подряд. Так, например, открытие файла с именем “\\.\A:” соответствует получению доступа к тому “A” (заметьте, что в программе на C это имя будет записано как “\\\\.\\A:”).

Все рассмотренные функции Windows API реализованы и в Win32 API, однако помимо них добавлено множество других, очень полезных функций. Правда реализация прежних функций несколько изменилась; так функция SetHandleCount при работе в Windows NT просто потеряла смысл — для описания файлов используется динамически выделяемое пространство, функции _lread и _lwrite полностью совпадают с функциями _hread и _hwrite соответственно. Многие из старых функций получили аналоги в Win32 API, обладающие несколько большими функциональными возможностями, например функции _lread и _lwrite имеют более мощные аналоги ReadFile, ReadFileEx, WriteFile и WriteFileEx.

Работа с томами

Win32 API предоставляет полный набор средств для работы с файлами и томами, в отличие от прежних версий Windows, которые часто использовали функции MS–DOS. Большинство функций Win32 API для идентификации тома используют не одну букву, и не номер тома, как это было в MS–DOS, а путь к корневому каталогу тома. Обычно это строка вида X:\, однако, в сравнительно редких случаях, возможно задание конкретного каталога.

Например, при работе с Windows 3.x и Win32s возможна работа 32х разрядного приложения в 16ти разрядной операционной системе, когда пользователь может обеспечить доступ к тому как к отдельному каталогу другого тома (используя команду join). В этом случае характеристики тома в целом и отдельного каталога этого тома могут существенно различаться — скажем, том является разделом жесткого диска, а один из его каталогов соответствует CD–ROM или RAM диску.