можно ли в ос windows при записи адреса файла использовать прямой слэш как разделитель

Урок 14
§ 12. Файловая система

Содержание урока

Дерево папок

§ 12. Файловая система

Дерево папок

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

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

Папка служит для группировки файлов и других (вложенных) папок.

В операционной системе Linux существует одна корневая (главная) папка (корневой каталог). Она обозначается символом «/», который называется «слэш». Остальные файлы и папки вложены в неё. Любое устройство (в том числе жёсткие диски, принтеры, сканеры и т. п.) в Linux считается файлом, т. е. входит в состав единой файловой системы (рис. 2.32).

В папке bin хранятся команды операционной системы, с помощью папки dev можно обратиться к устройствам, а в папке home находятся личные (домашние) папки пользователей.

Чтобы указать путь к файлу или папке, перечисляют (начиная от корня) все папки, в которых он находится, разделяя их символом «/». Например, адрес домашней папки пользователя petya запишется как /home/petya, а адрес файла с именем qq.mp4 в этой папке — как /home/petya/qq.mp4. Такой адрес файла часто называют полным именем файла.

В записи адреса файла или папки используют разделитель «\» (обратный слэш), например, чтобы найти файл по адресу

C:\Windows\System32\shell32.dll,

нужно перейти на диск С, войти в папку Windows, затем — в папку System32, и там искать файл shell32.dll.

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

Рабочая папка — это папка, в которой работает пользователь.

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

Следующая страница Имена файлов

Cкачать материалы урока

Источник

Slash и backslash: вехи на пути

Немного истории

Slash

Backslash

Боб Бемер ввел обратный слеш (\) в набор символов ASCII, 18 сентября 1961 года, как результат изучения частоты использования символов встречающихся в частности в программах на ALGOL’е. Тогда же вместе с обратным слешем в стандарт были включены и квадратные скобки.
В частности \ был введен, чтобы булевы операторы ALGOL’a AND и OR могли быть представлены с помощью ASCII символов как «/\» и «\/» соответственно [3,4].
Как же вышло, что исторически православный слеш заменился на свое зеркальное отображение, введенное как вспомогательный символ специально для уже мертвого языка?

Русскоязычная Википедия по этому говорит вот что:
В операционных системах DOS и Windows фирмы Microsoft и их аналогах других разработчиков, обратная косая используется для разделений имён директорий (каталогов) при указании пути к файлу. Прямая косая, применяемая для этого в Unix не могла быть использована в MS-DOS, потому что уже была задействована для указания ключей командной строки (оставшегося в наследство от СР/M, где MS-DOS команда «dir /w» писалась как «dir/w») [5].

Так как такое объяснение меня не слишком удовлетворило, пришлось найти статью «Why is the DOS path character «\»?» [6], которая вполне утолила моё любопытство. Вольный перевод избранных частей в моем исполнении:
То что символ «/» конфликтовал с разделителем пути другой относительно популярной ОС не был связан напрямую с разработчиками – в конце концов, DOS не поддерживал директорий, просто файлы в одном корневом каталоге.
Для MS-DOS 2.0 (в котором появился поддержка каталогов), дизайнеры DOSа выбрали гибридную версию – у них уже были имена дисков в наследство от DOS 1.0, поэтому разработчикам пришлось их использовать. И в дополнение к именам дисков они решили использовать *nix-style метод определения иерархии каталогов — вместо использования каталога в имени файла (как это было сделано в VMS и DEC-20), они просто сделали каталог и имя файла неотъемлемыми частями пути. Но с этим была проблема. Невозможно было использовать разделитель пути *nix (/), по той причине что слэш уже использовался как разделитель ключей.
Что им было делать? Они конечно могли использовать «.» как в DEC, но точка уже использовалась как разделитель между именем файла и расширением. Поэтому они выбрали наилучший вариант из оставшихся — символ «\», который был визуально похож на «/».Таким вот образом и был выбран символ «\» для разделения путей в DOS.
Кстати есть небольшой секрет про MS-DOS. Разработчики DOS не были довольны таким положением дел – они использовали Xenix [7] для почты и прочих вещей, поэтому они были знакомы со структурой *nix команд. Поэтому они добавили в ОС возможность принимать в качестве разделителя путей как «/» так и «\» (это работает и сегодня, кстати – попробуйте выполнить «notepad c:/boot.ini» под XP (если ваш пользователь имеет права админа)). Дальше — больше. Они добавили недокументированный системный вызов, чтобы изменить символ разделителя ключей. И обновили утилиты, чтобы те поддерживали этот флаг. Они даже добавили в config.sys параметр, SWITCHAR, который позволит пользователю установить разделитель ключей на «-«. Таким образом можно было превратить MS-DOS в *nix-style ОС, используя «-switch», и пути с разделителем «/».

Собственно к чему это все?

Меня побудила разобраться в этой теме следующая ситуация.
Была поставлена задача — наладить систему отчетов для автоматизированных тестов. Тесты у нас используются двух видов – Selenium (функциональные) и Jmeter (нагрузочные). Собственно в этом не было ничего сложного — для этих целей существует вполне себе open-source проект под названием logging selenium [8] и plugin для maven — chronos [9]. Настроив всё и протестировав отчеты локально, принялся за интеграцию с нашей CI — TeamCity. Вот тут-то меня и ждала та самая неожиданность, которая стала поводом для написания этой статьи.
После выполнения всех тестов отчет о Selenium-тестах имел следующий вид:

Всё отлично отображалось, и никаких отличий от локальной версии не было.
Но вот отчет, который отобразился для Jmeter-тестов, воодушевления не вызывал:

Напрочь отсутствовали все изображения на странице.
После просмотра исходного кода страницы стало понятно, что во всем виноват backslash. Ссылки на изображения были указаны в таком формате:

Справедливости ради стоит заметить, что изображения отсутствовали в Firefox, но прекрасно отображались в IE. Хотя если бы IE не отображал ресурсы в URI которых встречается обратный слеш, как разделитель пути для Windows, то в, и не без того подпорченной, репутации индийских программистов образовалась бы еще одна брешь.

Источник

Почему в путях Unix и Windows систем используются разные слеши

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

Однако как разделитель имен каталогов прямой слеш в UNIX стал использоваться только в 1970 году. Трудно сказать наверняка, почему разработчики выбрали именно этот символ, но наверняка этому есть разумное объяснение. Что же касается MS DOS, появившейся почти 10 лет после этого события, то в ней также стал использоваться прямой слеш, но не как разделитель имен каталогов, а как ключ командной строки, что явно указывает на прямое родство MS DOS с операционной системой СР/M, созданной еще в 1973 году Гэри Килдаллом.

В том, что в MS DOS 1.0 знак / не использовался как разделитель нет ничего удивительного, так как в первой версии Windows понятие структуры папок попросту отсутствовало. В версии MS DOS 2.0 появилась поддержка директорий, вот тут-то разработчики столкнулись с необходимостью построения иерархии каталогов. Поскольку прямой слеш оказался зарезервированным знаком, использоваться он уже не мог, не могла использоваться и точка (как в DEC), так как в Windows она служила в качестве разделителя между именем и расширением файла.

Выход из ситуации оказался простым. Вместо прямого слеша разработчики Microsoft решили использовать наиболее похожий символ. Таковым и оказался обратный слеш. Однако похоже на то, что разработчики Microsoft так и не удовлетворились принятым решением. Поэтому они решили реализовать поддержку обеих вариантов, и с того момента использовать в качестве разделителя путей стало возможно как прямой, так и обратный слеши. Можете не верить, но работает это и сейчас, правда с некоторыми ограничениями. Независимо от того выполните ли вы строку cd C:/Windows/Cursors или cd C:\Windows\Cursors результат будет один и тот же, в любом случае вы окажитесь в каталоге с курсорами. Тем не менее, использовать прямую черту в качестве разделителя путей не рекомендуется, так как в некоторых случаях это может привести к ошибке.

Источник

Форматы путей к файлам в системах Windows

Традиционные пути DOS

Стандартный путь DOS может состоять из трех компонентов:

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

В приведенном ниже примере показано различие между абсолютными и относительными путями. Предполагается, что каталог D:\FY2018\ существует и вы не установили какой-либо текущий каталог для диска D:\ из командной строки перед запуском этого примера.

Если вы хотите увидеть комментарии к коду, переведенные на языки, отличные от английского, сообщите нам на странице обсуждения этой проблемы на сайте GitHub.

UNC-пути

UNC-пути (универсальное соглашение об именовании) используются для доступа к сетевым ресурсам и имеют следующий формат:

Ниже приводятся некоторые примеры UNC-путей:

Пути к устройствам DOS

В операционной системе Windows используется унифицированная объектная модель, которая указывает на все ресурсы, включая файлы. Эти пути к объектам доступны из окна консоли и предоставляются на уровень Win32 с использованием специальной папки с символьными ссылками, с которыми сопоставляются устаревшие пути DOS и UNC. Доступ к этой специальной папке осуществляется с использованием синтаксиса пути к устройству DOS, который может иметь одну из приведенных ниже форм:

Помимо использования буквы диска, вы можете указать том с помощью его GUID. Синтаксис будет иметь вид:

Путь к устройству DOS состоит из следующих компонентов:

Описатель пути к устройству ( \\.\ или \\?\ ), который идентифицирует путь как путь к устройству DOS.

Символьная ссылка на «реальный» объект устройства (C: в случае имени диска или Volume в случае GUID тома).

Для UNC-путей к устройствам часть сервера или общего сетевого ресурса образует том. Например, в пути \\?\server1\e:\utilities\\filecomparer\ часть server1\utilities представляет сервер или общий сетевой ресурс. Это важно при вызове такого метода, как Path.GetFullPath(String, String) с сегментами с относительным путем к каталогу, поскольку переход дальше тома невозможен.

Пример. Способы задать ссылку на один и тот же файл

В следующем примере демонстрируются некоторые способы задать ссылку на файл с использованием API в пространстве имен System.IO. В этом примере создается экземпляр объекта FileInfo и используются его свойства Name и Length, чтобы отобразить имя и длину файла.

Нормализация путей

Практически все передаваемые в API Windows пути нормализуются. При нормализации в Windows выполняются следующие действия:

Нормализация осуществляется неявно, но при необходимости вы можете выполнить ее явно, вызвав метод Path.GetFullPath, который создает оболочку для вызова функции GetFullPathName(). Также можно вызвать функцию GetFullPathName() Windows напрямую с помощью P/Invoke.

Идентификация пути

На первом шаге процесса нормализации осуществляется идентификация типа пути. Пути могут относиться к одной из нескольких категорий:

Тип пути определяет, будет ли каким-либо образом применяться текущий каталог. Кроме того, от типа пути зависит применяемый корень.

Работа с устаревшими устройствами

Применение текущего каталога

Канонизация разделителей

Все символы косой черты ( / ) преобразуются в стандартные разделители Windows, то есть символы обратной косой черты ( \ ). Если они присутствуют, последовательность символов косой черты после первых двух таких символов свертывается в один символ косой черты.

Вычисление относительных компонентов

Если обнаруживается одна точка, текущий сегмент удаляется, поскольку он ссылается на текущий каталог.

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

Родительские каталоги удаляются только в том случае, если они не находятся после корня пути. Корень пути зависит от его типа. Это будет диск ( C:\ ) для путей DOS, сервер или общий сетевой ресурс для UNC-путей ( \\Server\Share ) и префикс пути к устройству для путей к устройствам ( \\?\ или \\.\ ).

Удаление знаков

Помимо удаленных ранее разделителей и относительных сегментов во время нормализации также удаляются некоторые дополнительные знаки:

Если сегмент заканчивается одной точкой, эта точка удаляется. (Сегмент, состоящий из одной или двух точек, нормализуется на предыдущем шаге. Сегмент, состоящий из трех или более точек, не нормализуется и фактически представляет собой допустимое имя файла или каталога.)

Если путь не заканчивается разделителем, удаляются все конечные точки и пробелы (U+0020). Если последний сегмент содержит только одну или две точки, к нему применяется приведенное выше правило для относительных компонентов.

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

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

Пропуск нормализации

Как правило, любой путь, передаваемый в API Windows передается в функцию GetFullPathName и нормализуется. Существует одно важное исключение: путь к устройству, который начинается со знака вопроса, а не с точки. Если путь не начинается с последовательности \\?\ (обратите внимание на использование канонической формы с обратной косой чертой), он нормализуется.

Зачем нужно пропускать нормализацию? Существует три основных причины:

Повышение производительности за счет пропуска нормализации в тех случаях, когда нормализация уже выполнена.

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

Регистр символов и файловая система Windows

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

Источник

Как мне создать имя файла с недопустимыми символами, такими как:?>?

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

отсюда вы можете найти альтернативные символы, которые выглядят одинаково, например:

(скопируйте и вставьте их, вы увидите, что они разные)

Вы можете загрузиться с диска Linux (например, Knoppix ) и смонтировать раздел NTFS.

Linux имеет гораздо меньше ограничений на имена файлов, и позволит вам создавать такие имена (я пробовал).

Некоторые операционные системы запрещают отображение определенных символов в именах файлов: (Ресурс из Википедии )

/ slash используется в качестве разделителя компонентов имени пути в системах Unix-like, Windows и Amiga. (Оболочка MS-DOS command.com будет использовать его как символ переключения, но сама Windows всегда принимает его как разделитель [2] [расплывчато])

\ backslash Также используется как разделитель компонентов имени пути в MS-DOS, OS / 2 и Windows (нет разницы между косой чертой и обратной косой чертой); разрешено в Unix имени файла

? знак вопроса, используемый в качестве подстановочного знака в Unix, Windows и AmigaOS; отмечает один символ Разрешено в Unix имена файлов

: двоеточие используется для определения точки монтирования / диска в Windows; используется для определения виртуального устройства или физического устройства, такого как накопитель на AmigaOS, RT-11 и VMS; используется в качестве разделителя пути в классической Mac OS. Удваивается после имени в VMS, указывает имя узла DECnet (эквивалентно имени хоста NetBIOS (сеть Windows), которому предшествует «\».)

| вертикальная черта обозначает программную конвейеризацию в Unix и Windows; разрешено в именах файлов Unix

«кавычка используется для обозначения начала и конца имен файлов, содержащих пробелы в Windows

больше, чем используется для перенаправления вывода, разрешено в именах файлов Unix

, период разрешен, но последнее вхождение будет интерпретироваться как разделитель расширений в VMS, MS-DOS и Windows. В других ОС, обычно рассматриваемых как часть имени файла, допускается более одной полной остановки.

Источник