Совместный доступ исходникам

Моя проффесиональная деятельность в основном связана с 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