return;

    }

    f.close();

  }

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

Небольшой нюанс. Приведенные выше функции выполняют специальное действие – стирание файла, если в качестве данных (строки или буфера) им передано значение null. В моей практике такое поведение оказалось довольно удобным. Действительно, при хранении текстовых данных в файлах может возникнуть ситуация «данные отсутствуют», которую проще всего идентифицировать с помощью значения null строковой переменной. В этом случае стереть файл (если таковой существует) – самое логичное решение. Проверять наличие файла перед вызовом метода delete() не нужно: при отсутствии файла (или при возникновении других проблем) метод delete() возвращает false, не порождая никаких исключений.

Путешествие по файловой системе: основные трудности

Средства для анализа файловой системы: для работы с каталогами и путями, определения системных свойств файлов, работы с файлами-ссылками (links) и пр. в Java, к сожалению, реализованы довольно непоследовательно.

Пакет для работы с файлами java.io.* был разработан в те времена, когда на рынке господствовали MS-DOS, ранние версии Windows и всевозможные варианты UNIX. В результате этот пакет хорошо «справляется» только с простейшими путями к файлам, подчиненными жесткой иерархии в соответствии с идеологией UNIX (эту идеологию унаследовала MS-DOS и вслед за ней Windows). А именно: имена файлов и подкаталогов, лежащих в некотором каталоге, образуются добавлением их имен к имени этого каталога через символ-разделитель File.separator («» – для Windows, «/» – для UNIX). В корне иерархии должен лежать общий для всех корневой каталог «/» – в случае UNIX, в случае MS-DOS и Windows – корневой каталог диска «C:», «A:» или аналогичный. Все средства объекта java.io.File, предназначенные для работы с путями, такие как File.getParent(), рассчитаны на эту логику.

В то же время все современные версии Windows с точки зрения пользователя организуют свою файловую систему совершенно иначе. Корнем иерархии обычно является «рабочий стол» («Desktop»). Его дочерними подкаталогами (или, если быть точным, дочерними узлами иерархии) являются «компьютер» («My Computer»), «папка с документами» («My Documents»), подкаталог для доступа к локальной сети («My Network Places»). Дисковые накопители появляются уже как дочерние узлы «My Computer».

При этом, разумеется, маршрут вроде: DesktopMy ComputerLocal Disk (C:)подкаталог в Windows никакого смысла не имеет.

Тем не менее для большинства приложений такая организация файловой системы никак не конфликтует с более простой логикой пакета java.io.* Дело в том, что «на нижнем уровне» с точки зрения функций работы с файлами даже самые последние версии Windows сохранили старую, унаследованную от MS-DOS структуру файловой системы: в корне находятся диски «C:», «A:» и т. д. Каталоги типа «Desktop» и «My Documents» соответствуют некоторым каталогам главного диска операционной системы: в случае Windows 2000/XP они расположены в каталоге текущего пользователя внутри каталога «Documents and Settings». Любой файл или «обычный» каталог таким образом имеет вполне традиционный UNIX-подобный «низкоуровневый» маршрут. Даже файлы из локальной сети Windows имеют традиционные UNIX-подобные «низкоуровневые» маршруты типа:

"\имя_компьютерапсевдоним_подкаталогаобычный_маршрут..."