Pull to refresh

Comments 14

/* Правда, мне не понятно, почему я не могу удалить одну жесткую ссылку на файл, если он открыт по другой жесткой ссылке. */

Ну с этим-то просто — это продолжение той же логики что не даёт удалить файл если он открыт другим процессом. В обоих случаях реальный файл один.
Ой, вру… Видимо, особенность реализации. Всё-таки позволить удалять в таком случае мне видится более логичным чем запрещать.
Вот вот. Я понимаю запрет записи. А запрещать удалять другое имя нелогично. Но видимо проще cтавить флаги на id файла (или как оно там называется), а не на каждое имя в отдельности.
А по-моему такое поведение вполне логично и любая другая реализация была бы шизофренией. В Linux — всё просто: открытый файл удалять можно — независимо от того, сколько у него имён. В Windows — тоже просто: нельзя удалять имена, если файл, на который они ссылаются, открыт. А вы что предлагаете? Запоминать имя, которое использовалось для открытия файла? Только для того чтобы устроить такое странное поведение??? Какой в этом смысл???
Вывод прост — авторы некоторых вышеуказанных программ не знают об этой возможности NTFS.

Ещё есть похожий интересный вопрос. Недавно на Хабре проскакивало, что Windows в приципе в ядре различает регистр символов в именах файлов. (То, что NTFS их различает, известно давно.)
Так вот, насколько больны программы этим? Насколько они чувствительны к регистру; если я создаю файл большими буквами, может ли программа создать его маленькими?

Вопрос тем более интересен, что ведь в Windows можно посредством IFS-драйвера подключить ext2/ext3 (и даже разместить там своп-файл). Насколько сильно удивятся программы, когда увидят в одной директории два разных файла: test.txt и Test.txt?
>Насколько сильно удивятся программы, когда увидят в одной директории два разных файла: test.txt и Test.txt?

Программы не удивятся вообще, поскольку даже не узнают, что этих файлов там 2 — драйвер «выдаст» (или не выдаст) программе необходимый файл. Т.е. если программа попросит у драйвера test.txt — то он ей выдаст именно этот файл, а не Test.txt

Что касается NTFS — поддержка case-sensetive имён файлов реализуется флагом FILE_FLAG_POSIX_SEMANTICS в функции Create File. Т.е. если этот флаг стоит, то драйвер NTFS будет отдавать этот файл только по его точному имени.
Вы бы попробовали проверить то, что поёте, а? Программы таки получают два файла в списке и с открытием творится бардак. Что там отдаёт драйвер NTFS — одному богу ведомо, а вот что отдаёт Windows — известно: один какой-то файл независимо от того, какой запросили (однако просмотр каталога через FindFirstFile/FindNextFile выдаст две записи, а не одну). Вот если и при создании файла и при открытии задавать флаг FILE_FLAG_POSIX_SEMANTICS — тогда всё честно, а вот если при создании его задать, а при открытии нет… весело будет… А с учётом того, что мало какие программы позволяют этим флагом управлять… Лучше так не делать — вот и всё что на эту тему можно сказать…
Объясняю:

1) Первый мой абзац касается драйверов ext2 под виндовс, поскольку там наименование файлов происходит «честно», то их содержимое отдаваться просто по имени.

2) С NTFS всё сложнее — дело в том, что CreateFile отдает один и тот handle на всё файлы с именами различающимися только регистром, поэтому приложение будет получать содержимое одного и того же файла если обращается к нему через OpenFile например. Причем будет возвращаться содержимое того файла, у которого имя в строковом представлении больше чем у других (это моё эмпирическое исследование), например если создано 3 файла TEST > TEst > test — то сначала будет возвращаться содержимое TEST, если удалить какой-то из файлов — то будет возвращаться содержимое TEst и т.д. Поэтому я согласен, что последнее мое предложение было несколько опрометчивым.

У меня под Windows на C:\ сейчас два каталога, «Work» и «work» :) При попытке войти в любой из них входит только в один из них.

Сделал по ошибки из под Linux, грохнуть лишний всё забываю, когда сижу в Linux и не могу, пока сижу в Windows ;)
Был у меня когда-то пример для работы с символьными ссылками. Скрипт .bat на пару строк.
Теперь у меня в обной папке есть ссылка…
Free Image Hosting at www.ImageShack.us

Видит её только тоталкоммандер или фар, эксплорер не видит.
И не удаляется ни чем.
Не понимаю, я вас граждане — ни автора этой заметки, ни предыдущей: почему вы сразу начинаете писать исключительно собственные измышления. Ладно — писать, но публиковать-то зачем, если не разу не заглянули в официальную документацию?!
В MSDN чётко написано, что soft links и symbolic links — разные сущности. Вы же сами таким фразочками:
с мягкими или символьными ссылками есть путаница. Так вот я далее буду говорить о тех символьных ссылках которые делаются программой Junction
путаницу только увеличиваете.
Более того: устоявшийся термин символические ссылки, а не символьные — именно так они упоминаются в справке Windows и огромном количестве литературы по Unix, Linux, Windows.
Что касается «фактов о не очевидном поведении этих ссылок» — поведение меняется в зависимости от версии Windows — о чём опять же на сайтах MS написано, даже с примерами:
Under Windows Server 2003, if you copy %systemroot%\SYSVOL, you do not copy the junction points. However, under Windows 2000, if you copy %systemroot%\SYSVOL, you do copy the junction points.
У вас даже не указано на какой XP вы экспериментировали: 32 или 64, какой SP.
Ладно — писать, но публиковать-то зачем, если не разу не заглянули в официальную документацию?!
Затем что официальная документация сама себе противоречит. То, на что вы сослались — всего лишь последняя версия сказки о символьных ссылках. То, что Microsoft любит давать одинаковым вещам разные названия и разным вещам одинаковые — ни для кого не секрет (чего стоит одно переименование ISO9660 в «Mastered», а UDF — в «Live File System») и то, что фразы типа directory symbolic links are known as NTFS junctions in Windows до сих пор встречаются на сайте этой замечательной фирмы не делает вещи проще и понятнее...
Что касается «фактов о не очевидном поведении этих ссылок» — поведение меняется в зависимости от версии Windows.
Это делает оное поведение более очевидным? Вот в Unix/Linux где символьные ссылки появились не одно десятилетие назад и где поведение не зависит от версии — там всё просто и понятно. А в Windows… тёмный лес и куча дров…
Учел замечания — указал версии программ. Но что касается названий. Воспользуемся сайтом microsoft.com
от сюда первая цитата
«Windows 2000 and higher supports directory symbolic links, where a directory serves as a symbolic link to another directory on the computer. For example, if the directory D:\SYMLINK specified C:\WINNT\SYSTEM32 as its target, then an application accessing D:\SYMLINK\DRIVERS would in reality be accessing C:\WINNT\SYSTEM32\DRIVERS. Directory symbolic links are known as NTFS junctions in Windows.» С моим скромным английским я понял так, что символические ссылки на директорию известны так же как junctions.
Смотрим отсюда " A junction (also called a soft link) differs from a hard link in that the storage objects it references are separate directories, and a junction can link directories located on different local volumes on the same computer."
junction так же именуемые как мягкие ссылки. Банальная транзитивность предполагаемая в таких случаях приводит к тому что если «символические ссылки==junctions» и «junctions== мягкие ссылки» то «символические ссылки == мягкие ссылки»
Как вы понимаете, если фича реализована по-разному в разных версиях системы, это всё равно, что фичи нет. (А что, даже в разных XP по-разному!? Иначе — зачем указывать, какая именно XP?)
Sign up to leave a comment.

Articles