Моя проффесиональная деятельность в основном связана с Linux, хотя последние 6 лет на рабочем компьютере установлена Windows. Я делал несколько попыток пользоваться WSL, когда он только появился в Windows, но каждый раз опыт был негативный. Частые зависания подсистемы Linux и приходилось перезагружать Windows. Не работал Docker и некоторые другие программы. В то же время у меня появилась виртуальная машина VirtualBox с Debian внутри, которая после нескольких обновлений работает и по сей день. Вначале я пользовался shared folders в VirtualBox чтобы была возможность запускать IDE в Windows, но запускать программы в Linux. Это работало, но с определенными проблемами.
Поскольку в Windows выполнялось только редактирование файлов, то рациональным решением стало переносом их на сторону файловой системы Linux, а Windows становилась клиентом. Для этого я настроил NFS сервер в Linux и подключал его через NFS клиент Windows. С таким подходом тоже были нюансы, но такая схема успешно продержалась до прошлого года. Определенную головную боль приносило создание директорий в Windows (т.к. при монтировании в Windows использовалась опция -o fileaccess=644, то директории создавались, но зайти в них было нельзя), но если создавать их в Linux, то все работало нормально. Еще где-то полгода назад появилась проблема с сохранением файлов из Windows (ругалось что файл занят и запись невозможна, но кроме Windows с этим файлом никто не работал) - возможно виноват какой-то из дополнительных "агентов", которые установлены на рабочем компьютере.
Параллельно следил за развитием WSL2 в котором по-сути запускается урезанная версия Linux в которой работает все необходимое, но вот скорость работы отличается не в лучшую сторону. Время сборки проекта могло отличаться в разы если сравнивать запуск в VirtualBox и WSL2. Так что с WSL2 у меня тоже не сложилось.
Перед новым годом решил попробовать перейти с NFS на Samba. Решилась проблема с периодическими ошибками сохранения файлов, директории теперь создаются без проблем в Windows. Чтобы не мучиться с правами на файлах настроил сохранение DOS атрибутов в XATTR. Для этого нужно смонтировать файловую систему с опцией user_xattr и добавить в настройки share несколько параметров:
[work]
path = /work
store dos attributes = yes
map readonly = no
map system = no
map hidden = no
map archive = no
Теперь если файл или директория создается в Windows, то DOS атрибуты не влияют на права файлов или директорий
$ ls -ln /work/project/.gitignore -rw-r--r-- 1 1000 1000 10 Jan 20 18:41 /work/project/.gitignore $ attr -l /work/project/.gitignore Attribute "DOSATTRIB" has a 32 byte value for /work/project/.gitignore
В прошлом году в Git закрыли уязвимость CVE-2022-24765 которая проявлялась на многопользовательских окружениях. Сейчас Git проверяет владельца файлов и ругается если они принадлежат кому-то другому
Z:\project>git status
fatal: detected dubious ownership in repository at '//192.168.123.100/work/project'
'//192.168.123.100/work/project' is owned by:
'S-1-5-21-1311346689-1669112243-747071350-1000'
but the current user is:
'S-1-12-1-1311346689-1669112243-713507470-1777833723'
To add an exception for this directory, call:
git config --global --add safe.directory '%(prefix)///192.168.123.100/work/project'
Поскольку на моем компьютере работаю только я, то можно вернуть прежнее поведение Git и разрешить все пути
git config --global --add safe.directory "*"
Вторая проблема относится к executable bit, который Windows не поддерживает
Z:\project>git diff target-build.sh diff --git a/target-build.sh b/target-build.sh old mode 100755 new mode 100644
Проще всего отключить эту проверку в Windows версии Git
git config --global core.filemode false
Комментариев нет:
Отправить комментарий