Почему Linux git при запуске в Windows WSL и работе в файловой системе NTFS не создает правильную символическую ссылку Windows?

Question

Когда я запускаю оболочку WSL bash, я могу использовать команду "ln -s" для создания символической ссылки. Независимо от того, работаю ли я в файловой системе NTFS или в файловой системе WSL, ссылка Symboli c создается в соответствии с ожиданиями. В частности, ссылка в файловой системе WSL работает так же, как символическая ссылка Linux, а символическая ссылка в файловой системе NTFS является символической ссылкой Windows, и я могу использовать ее как из WSL, так и из Windows.

Сравните это с тем, как работают символические ссылки в Linux версии git, работающей в WSL. Я клонирую репозиторий, содержащий символические ссылки на файловую систему NTFS. Я не уверен, что это за ссылки, но они определенно не являются Windows символическими ссылками.

Некоторые могут сказать, что я должен использовать Git для Windows, который создает правильную символическую ссылку Windows, когда Я клонирую репо. Единственная проблема заключается в том, что у нас есть инструменты, написанные как bash сценарии, которые все используют, и эти инструменты вызывают git. Они отлично работают на Linux, но из WSL они не работают должным образом из-за проблемы с символьной ссылкой. Я обнаружил, что мне нужны все инструменты разработчика командной строки для запуска в WSL, чтобы они могли вызывать друг друга и передавать пути к файлам и env-переменным и тому подобное. Так что на самом деле я не могу запустить Git для Windows.

Есть ли какие-либо средства, чтобы решить эту проблему? Если оболочка WSL bash может функционировать должным образом, то, безусловно, небольшое изменение в Linux версии git также может решить эту проблему. Это пахнет какой-то философской борьбой между Windows и Linux. Или существует наследие этого, которое предшествует Git для Windows ... В этом случае, безусловно, есть способ включить новую обработку символических ссылок для тех, кто хочет использовать Windows символические ссылки.

Answer 1

Это, вероятно, проблема в Windows и подсистеме Windows для Linux.

В эмулируемой среде Linux создаются символические ссылки с использованием системного вызова symlink(2), очень похожего на ln -s команда делает.

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

Стандарт Git, поставляемый восходящим потоком, проверяет, можно ли использовать символические ссылки. создал указатель на файл, который не существует. Это важно, потому что Git не нужно проверять файл назначения перед символической ссылкой. Если это не удается, Git устанавливает core.symlinks в false, и вместо этого записываются файлы с содержимым символических ссылок. WSL не может создать символическую ссылку правильного типа, когда этот тест выполняется (потому что нет места назначения), и, следовательно, операция не выполняется.

Git для Windows, вероятно, имеет некоторые функциональные возможности, чтобы обойти это проблема с символическими ссылками в Windows. Он также имеет огромное количество патчей, которые не включены в версию, поставляемую апстримом, и, следовательно, не являются версией, используемой большинством Linux дистрибутивов.

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

Вы можете попробовать запустить git config core.symlinks true в репозитории fre sh и посмотрите, работает ли он так, как вы ожидаете; это может или не может. Если это не так, вы можете увидеть, отправит ли сопровождающий Git для Windows исправление, которое он использует в апстриме, и он может в конечном итоге быть включен в более новую версию Git, и, следовательно, в более новой версии Linux дистрибутивов. Однако, поскольку Linux дистрибутивы обычно предоставляют стабильные версии, это займет время, обычно порядка нескольких лет, если вы не свернете более новый пакет.

В целом, однако, вы не можете ожидать Unix код для адекватной работы в файловой системе NTFS, поскольку она принципиально отличается, и Microsoft даже документирует это поведение. Microsoft знала (или должна была знать), когда они добавляли символические ссылки, как функционировали символические ссылки Unix, и по какой-то причине они решили сделать это по-другому. Я лично считаю, что это было ошибкой, и вот мы здесь.