Comments 100
Хмм.. Не вижу потоков NTFS.
Там так весело перевели "скрытые фрагменты файлов" , похоже )
Малоизвестно, что в некоторых контекстах можно хранить внутри файла скрытый фрагмент данных, добавляя к его имени суффикс, которому предшествует двоеточие.
Концепция была прикольна изначально, но потерпела крах из-за несовместимости с любой другой файловой системы. То есть копируя такой файл на любую другую, или просто пытаясь приаттачить такой файл любым сервисом - сложно придумать как это правильно делать...
Тем не менее на Макинтоше resource forks активно использовались и прожили достаточно долго.
Когда-то давно встречал, что таким способом антивирус Касперского проставлял хэш файла, и при быстрой проверке его проверял.
мне казалось что это майкрософтовский антивирус мог делать. Ну и вообще это удобный способ хранить любую метаинформацию о файле, особенно в пределах текущей ОС или ФС.
Но она оказалась реально невостребованной. Я когда впервые про нее прочитал (лет 20 назад), очень тащился и даже в каком-то файле секретно хранил информацию. Но вот в бэкапы она не попадала, скопировать на дискетку или флешку оказалось проблемно, перестал пользоваться. А за годы обнаружил, что так никто особо и не начал массово пользоваться потоками.
В общем и идея и реализация - интересная, а вот массового применения так и не нашла =(
майкрософтовский антивирус мог делать
Оба, еще аваст этим баловался. Сам проводник и IE оставляют мету — помните этот файл был получен из небезопасного местоположения или как-то так?
Самое распространённое использование потоков - это пометка, что файл скачан из интернета :)
Когда-то читал, что потоки добавили в NTFS для того, чтобы WinNT могла служить файловым сервером для Маков.
Вот что получается когда нет базарной концепции «все файл» как в Unix/Linux
Путь к устройству (нормализованный)
Еще такие пути есть:
\\?\usb#vid_0dd4&pid_015d#vkp80_200num.:_0#{28d78fad-5a12-11d1-ae5b-0000f803a8c2}
\\?\hid#vid_23d8&pid_0285#8&a477d5c&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
И еще костыли для ipv6 адресов например FE80::1%12
\\FE80--1s12.ipv6-literal.net\C$\Chameleon
Справедливости ради, такой legacy-зоопарк есть не только в Windows. В той же macOS есть свой отдельный филиал ада со старой (времён классических MacOS) нотацией путей через разделение двоеточием вместо слеша, и всё это счастье продолжает поддерживаться на уровне AppleScript, ObjectiveC и Finder. Последний даже не даст пользователю создать имя файла или папки с двоеточием, хотя такие имена отлично поддерживаются HFS+ и APFS и их можно дать через терминал.
Кроме того, есть alias-ы папок и файлов, по путям которых отлично переходят все системные диалоги, скрипты и команды, но которые не понимаются ни одной консольной программой на уровне терминала, потому что натыкаются на сам файл ярлыка. И подобного добра выше крыши.
Да и чего греха таить, и в *nix много весёлого, одни рекурсивные симлинки чего стоят, не говоря уже про экранирование пробелов слешами и переносы строки внутри имени файла :)
Экранирование пробелов — это особенность оболочки, а не файловой системы. Оно, к слову, и на винде работает, только символ экранирования другой.
Попробовал двоеточие в Finder, не работает (у меня Вентура).
Файндер двоеточие использует для представления слеша в визуальном имени файла. Например, если создать в файндере папку Apple //e, то на диске каталог будет иметь имя Apple ::e
"C:\ProgramData\Application Data" которая ссылается (посредством junction) на саму себя, чем приводит в восторг множество программ рекурсивного обхода файловой системы, есть в большинстве современных установок Windows...
Про регистрозависимость со стороны ядра и API хорошая статья: NTFS Case Sensitivity on Windows
А еще не рассмотрены сетевые DFS-ссылки, которые выглядят почти как UNC-пути, но тоже отличаются:
\\имя_домена\имя_DFS-корня\имя_DFS-ссылки\и т.д.
Например:
\\ROGA_AND_KOPYTA\PRIVATE-STORAGE\XXX$\NEW-2023-YEAR\Secretar.avi
C:\CHAMELEON будет доступно и как C:\CHAMEL~1, что умножает способы… можно дополнить в пост.
В статье довольно много неточностей, уж не знаю связано ли это с переводом.
Начнем с того, что "всё начинается со слеша - то это путь", это неверно: относительные пути со слеша не начинаются.
Второе, например, путь относительно корня диска в терминологии виндовс всё таки называется абсолютным, а не таким вот вот странным.
Ну т.е., претензий никаких, но терминологическая запутанность явно присутствует.
Насчет путей \\?\ и \\.\ тоже не совсем ясно, символические милипиздрические... Самое главное, на мое имхо, что пути в такой форме могут иметь длину в 32К без глобального включения фичи в реестре.
Т.е. заминусовавшие расписались в своей профнепригодности. Учтем, все на карандаше. :)
Начнем с того, что "всё начинается со слеша - то это путь", это неверно: относительные пути со слеша не начинаются.
То, что "относительные пути со слеша не начинаются." не делают неверным утверждение, что "всё начинается со слеша - то это путь".
"Пути файловых систем в Windows страннее, чем можно подумать. В любой производной от Unix системе пути на удивление просты: если нечто начинается с /, то это путь. Но всё совершенно иначе в Windows, которая имеет озадачивающее разнообразие схем составления пути."
Цитата выше имеет логическую несогласованность, как минимум. А точнее - искажение действительности. Точно так же можно сказать - удивительно, но в Windows всё что начинается на \ - это имя объекта ядра, а заодно и файла.
При этом как не скажи - но пути не определяются наличием слэша вообще. Путь это просто строка. Путь - всегда относителен от текущей директории. Вы думаете что они всегда от корня парсятся? А почему вы так думаете? А вы знаете, что операции относительно текущей директории на линуксе и как минимум в авязке с ext4 - быстрее чем с абсолютными?
И вы утверждаете что всё что начинается со слэша это путь? Путь это строка. Её путем делает лишь место использования, но никаа не форма. И то что строки начинающиеся на слеш вдруг похожи на путь - не делают их путем в ОС. Посмотрите на пути в современных билд-системах или те же веб сервера где пути внезапно выглядят так же, только они являются виртуальными.
Да и не все абсолютные пути могут начинаться не со слеша.
~ это вполне себе абсолютный путь. не со слеша.
Разве? А не относительный относительно домашней директории текущего пользователя?
ну домашняя директория - она статична, тем более что я могу указать конкретного ~user1, или еще лучше ~root
Основной момент, что эта директоря не меняется в зависимости от моей текущей рабочей директории, то есть на конкретной машине она всегда абсолютна.
домашняя директория - она статична
Никто не мешает перекинуть в другое место и поправить /etc/passwd.
Согласно общепринятой терминологии, relative path считается относительно текущей рабочей директории, а не относительно чего-либо еще.
Я соглашусь, что ~ работает относительно директории пользователя, это логично.
Но как термины, relative path и absolute path привязаны только относительно текущей рабочей директории.
Ну уж нет, относительные пути считаются относительно базового, который вовсе не обязательно является текущей директорией. К примеру, при чтении конфига хорошим тоном является использование директории конфига в качестве базовой независимо от текущей рабочей директории процесса.
Давайте может быть все-таки почитаем документацию, что такое относительный путь?
Потому что базовый путь он не относительный, он просто хранится в переменной и определяется при запуске
Если вы прописали путь к конфигфайлу в виде $BASE/config/my.cfg, это не относительный и не абсолютный, это неизвестный, потому что нужно посмотреть что внутри $BASE - она может быть как пустой (тогда будет абсолютное /config/my.cfg), может быть ../envs/prod и получим относительный ../envs/prod/config/my.cfg, может быть /opt/myapp/envs/prod, и получим абсолютный /opt/myapps/envs/prod/config/my.cfg
в любой документации сказано, что относительный считается относительно working directory текущего процесса. То есть еще раз поставлю ударение - это не вопрос философии что считать относительным, это вопрос архитектуры любой ОС, у которой у каждого процесса есть ее текущая/рабочая директория. И пути всегда считались относительно этой директории. У процесса нет другого поля, с домашней директорией пользователя, например. Поэтому все остальное - за рамками терминологии.
А давайте такие фундаментальные вещи, как абсолютный и относительный путь, не будем читать в документации на конкретную программу?
Кстати, откуда у вас взялась переменная $BASE?
А откуда у вас взялась "базовая директория"?
В какой архитектуре операционки или процессов есть такой термин?
Это вообще не из архитектуры ОС термин, а из языка.
Напрямую он используется, например, в RFC на URI. Аналогов про пути к файлам я не нашёл, но, видимо, лишь потому что никто не думал что такие очевидные вещи вообще должны включаться в какие-то стандарты.
Хм, в rfc вообще все довольно запутано и очень хай-левел спецификация. Файловая система очень маленький частный случай URI, и практически не упоминаются примеры для файловых систем. Тем не менее если полазить, то в некоторых случаях абсолютный путь для дос/виндовс может начинаться не со слеша а с буквы диска.
Ок, по rfc свою точку зрения доказать не могу, сорян =)
В Windows? Результаты экспериментов ниже:
1) консоль powershell действительно переходит на домашний каталог.
2) cmd - ругается
3) Far manager - переходит на C:\Program Files\Far Manager
4) os.chdir('~') в питоне генерирует ошибку.
Ну и даже если бы это работало на уровне файловой системы - то этот путь разный для разных пользователей.
разве его не шелл разворачивает в абсолютный путь (согласно переменной $HOME)?
Например в python, open() на файл с ~ будет ругаться, а питонячья std это почти везде тоненько обернутая C std. Для того чтобы развернуть путь с ~ нужно вызывать отдельную функцию
Эм. Это ж вообще не путь, это шаблон шелла, эквивалентный $HOME и точно так же требующий раскрытия перед применением.
Не делает эту часть предложения. Но все предложение уже не выглядит убедительным.
А какая профессия у заминусовавших?
Не знаю, насколько это известная возможность, но используя busybox в Windows можно делать, например, такие штуки:
dd if=\\.\PHYSICALDRIVE1 of=image.dd
И оно даже работает. Сами пути можно выцепить через wmic diskdrive list brief. Хотя в никсах, конечно, всё проще.
Не знаю на сколько это в тему. Но имена папок и файлов с пробелами надо постоянно заключать в кавычки. Что часто по разному интерпретируется консольными утилитами. Видимо единого стандарта просто нет
Я плохо знаю с какими сценариями вы сталкивались, скажу только что командная оболочка из аргумента автоматически уберет двойные кавычки.
Т.е. cl.exe "foo" "bar baz"
даст самому процессу cl.exe два аргумента, foo и 'bar baz' без двойных кавычек снаружи.
при вызове других процессов программными способами, конечно зависит от API/языка, но подавляющее большинство я бы сказал - если подразуемвается массив аргументов, то самому добавлять кавычки не нужно. Если подразуемвается "commandLine" как одна сплошная строка, тогда будь добр всё пробелосодержащее откавычить сам (включая другое необходимое экранирование)
Это особенность консоли и консольных программ, а не путей к файлам.
И да, единого стандарта просто нет — каждая программа парсит командную строку по-своему. Хотя большинство программ в этом полагаются на стандартную библиотеку, а их создатели смотрят друг на друга, так что в целом экранирование работает примерно одинаково.
Запрещённые имена
По историческим причинам нельзя использовать следующие имена
Их можно создать через коммандную строку указывая путь к папке/файлу через устройство (\\.\ в начале пути). Я так еще с xp лочил autorun.inf от вирусни на флешках (создавая файл \\.\z:\autorun.inf\com1), потом еще файлы в место папок куда вирусы копируются, но против червей которые из всех файлов ярлыки делают это не канает.
да и запрещенных символов сильно меньше, чем кажется. те же ? и * (а так же <>: как минимум) вполне себе создаются с помощью touch file\?\* из WSL1 (и вроде бы из cygwin). правда проводник не сможет нормально показать имя такого файла. в терминале показывалось нормально.
и еще может быть очень весело такое удалять.
помнится как-то решил переехать на винду, собрал конфиги нужного софта и накатив емнип 7ку стал всё приводить к привычному рабочему состоянию. Было много приколов в основном связанных с переносами строк и путями в конфигах, но один запомнился на всю жизнь:
eiskaltdcpp сохранил в настройках дефолтный путь для скачивания файлов /home/werwolf/Загрузки/ и когда я поставил скачиваться какое-то кинцо он не поругавшись ни на что скачал его.. вот только я не понял куда.. место на диске C: занято, но ни проводником ни far manager'ом ни чем другим я так и не нашёл где оно лежит..
благо что решать проблему не пришлось, когда винда тем же вечером после обновления перестала грузиться показывая мне знаменитый синий экран я махнул рукой и вернулся на opensuse.
/home/werwolf/Загрузки/ — это вполне корректный путь к папке \home\werwolf\Загрузки\ на текущем диске, странно что вы его не нашли.
Но довести "семёрку" до синего экрана за один вечер — это сильно, что вы с ней делали?
/home/werwolf/Загрузки/ — это вполне корректный путь к папке \home\werwolf\Загрузки\ на текущем диске, странно что вы его не нашли.
теорию я знаю, на практике на диске такого пути не было, и по имени и файла и промежуточных директорий искать было бесполезно
Но довести "семёрку" до синего экрана за один вечер — это сильно, что вы с ней делали?
дык её для этого даже трогать не надо, она сама справится
P.S.: как активно сектанты свидетелей виндовы минусуют любой негативный комментарий об их предмете обожания, забавно))
P.S.: как активно сектанты свидетелей виндовы минусуют любой негативный комментарий об их предмете обожания, забавно))
Ваш комментарий попросту неуместен.
Я вот тоже могу рассказать историю про то как решил завязать с пиратством и перейти на убунту, но при очередном обновлении у неё отвалились иксы. Но почему-то я не бегаю по "линкуксовым" постам с этой историей и не рассказываю "свидетелям линукса" как у них всё плохо и не работает.
теорию я знаю, на практике на диске такого пути не было, и по имени и файла и промежуточных директорий искать было бесполезно
Хм, а C:\Users\werwolf\AppData\Local\VirtualStore\ смотрели?
простите но я не понимаю к чему этот вопрос и как на него ответить. могу предложить вам такие варианты ответов:
1) естественно find (ну или кто там под капотом у far manager) пробегаясь рекурсивным поиском по директориям заглянул и в эту
2) за давностью лет (напомню что речь идёт про семёрку) уже не помню какие были директории на разделе но да я проверил все
не думаете же вы что я делал это исключительно глазками через проводник? для задач поиска файлов на диске есть утилиты благодаря которым нет необходимости делать это руками. и если утилита не смогла найти то врятли смог бы человек.
Да, недавно узнал про эту тему, пытаясь понять, где лежат сейвы BG1 на семёрке. В очередной раз поразил масштаб работы Microsoft над backward compatibility - даже странно, что они при этом убрали поддержку 16 битных приложений на x86-64, а не встроили dosbox или что-то в этом роде для прозрачного запуска.
Там нет сортировки по дате разве? Да везде должна быть. Да и вроде бы там банальный cmd весьма быстро тебе найдёт что угодно, насколько помню работает даже "dir /s зеленый_слоник_не_вирус.avi.exe" и просто "dir /s зеленый*".
Совершенно не раскрыта тема расширения. Которая в принципе требует введения отдельных терминов для просто имени файла и полного имени файла - т.е. включающего расширение и отделяющую его точку. Без чёткого разделения этих двух понятий, например, следующее утверждение
Любопытно, что Windows допускает пробелы в начале, но не в конце имён.
воспринимается как потенциально ошибочное. Особенно с учётом того, что по умолчанию интерфейс проводника скрывает расширения файлов.
Любопытно, что Windows допускает пробелы в начале, но не в конце имён. Так как имя с пробелами в начале и конце часто выглядит похожим на имя без пробелов, обычно это ужасная идея, и при переименовании или создании файлов Fileside автоматически удаляет их.
выполнить файл с ведущими пробелами будет сложноватенько, потому что функции API CreateProcess() и ShellExecute() такие команды не жрут. пробел отделяет имя запускаемого файла от параметров. таким образом получается имя файла нулевой длины.
Было бы так — нельзя было бы запускать программы из Program Files.
Кавычки же.
Винда ищет имя программы пока не найдет: "C:\Program Files\My Program\app.exe --arg1" - это без кавычек (по памяти):
"C:\Program"
"C:\Program Files\My"
"C:\Program Files\My Program\app.exe" - нашлось!
"C:\Program Files\My Program\app.exe" --arg1
UNC-путь
\\Media\Pictures\Worth\1000 word
Возможно, я ошибаюсь, но разве такой формат пути характерен именно для Windows? В Linux же, вроде как, точно такой же синтаксис сетевых путей?
В Linux исторически для доступа к удалённым файлам используются не сетевые пути, а монтирование директорий. И на уровне системы поддерживается только оно.
Если вы видите где-то в линуксе подобный UNC-путь — это либо "творчество" используемого вами файлового менеджера, либо подключение к виндовой сетевой папке, либо и то и другое одновременно.
Но чтобы смонтировать директорию, надо же каким-то образом указать сетевой путь до нее. Он же указывается точно так же, разве нет?
я монтирую как mount //172.16.2.5/d$ /mnt/server-02-05/d$ -o options
возможно, под капотом прямая черта в сетевом пути меняется на обратную
Это вы написали вариант "подключение к виндовой сетевой папке".
Если что, шары NFS или какой-нибудь SSHFS записываются в совсем другом формате.
Когда ишак (ещё не имевший вкладок) при сохранении страницы в HTML оставлял в имени угловые скобки, сохранённые им файлы спокойно читались… Позже приходилось заменять их ‹похожими› character`ами, но сейчас использую ＜Ｆｕｌｌｗｉｄｔｈ＞ аналоги… правда и тут довелось наткнуться на одну программу, умудрившуюсь "не найти" и такой файл, причём в самой винде «язык для программ не поддерживающих Юникод» китайский/япоский/корейский задан, т.е. делает абсолютно никому не нужное преобразование пути в совершенно «левую» кодировку…
Про папку ".." , вроде как на NTFS-разделах винда то ли не позволяет создать, то ли chkdsk её "чинит" (поправьте меня), т.е. только на FAT`ных, а то хотелось попробовать создать её на маке вместе с "тут же проникшими" .Spotlight-V100 .fseventsd .Trashes в корень флешки, проигнорировав ACE-запись D:P(D;OI;0xD0156;;;S-1-1-0)…
Занятно, что не была затронута тема кодировки имён в UTF-16, хоть это напрямую и не относится непосредственно к Windows, но таки тоже может стать проблемой.
Статья понравилась. Может не какой-то лютый хардкор, но как справочник - самое оно. Возможно Windows-разработчики это всё держат в уме по умолчанию, но я бОльшей частью линуксоид, но иногда заносит в виндовый мир и хорошо иметь такой справочник под рукой.
Вот что получаешь, когда приходится обеспечивать полную обратную совместимость в течение нескольких десятилетий!
А с другой стороны ты ставишь обновление и у тебя отваливается система. Везде свои "приколы"
Традиционно длина пути в Windows не могла превышать 260 символов. Даже сегодня это справедливо для некоторых приложений, если только их разработчики не предприняли мер для обхода этого ограничения.
Больше всего раздражает, что в число этих приложений входят и последние версии приложений MS Office. Вот так сначала учишь пользователей красиво и понятно именовать и раскладывать файлы по папочкам - а потом они приходят с вопросом "а что это у меня никакие docx из папки не открываются, а pdf из той же папки открываются".
Иногда очень хочется, что бы Microsoft выкинули весь этот легаси и сделали бы с нуля свою UNIX based операционную систему, в которой UI/UX был бы на уровне Windows 10 и можно было бы в режиме совместимости запускать Windows программы (Windows subsystem for Linux?).
Странный мир путей файлов в Windows