При совместной работе windows/linux(терминал) в терминальных сессиях в Mandriva linux 2009.0 не выполняется преобразование регистров символов в именах ФАЙЛОВ (с именами директорий всё OK) расположенных на примонтированных ресурсах. Например создаём файл "ёf", потом создаём файл "ЁF" получаем 2 файла, с директориями такого нет - при попытке создания папки "ЁF" при существующей "ёf" как и требуется получаем file_exists. Символы кириллические, латинские, символы с умлаутом или в перемешку не влияют ни как, длинна имени файла тоже. Результат: из под терминальных сессий не открывается 1с77 (Ошибка загрузки метаданных.), у windows клиентов всё OK. Тоже самое наблюдалось на старой Mandriva 2008.0/1, после перехода с cifs на smbfs ЭТА проблема исчезла. В качестве терминального сервера используется Mandriva 2009.0 (ядро kernel-server-2.6.27-0.rc8.2mnb), диск монтируется в папку пользователя ~/1c cледующим образом: mount -t cifs -o gid=x,uid=x,rw,noperm,nocase,iocharset=utf8,codepage=cp866,ip=xxx.xxx.xxx.xxx //xxxxx/1c ~/1c общие диски распологаются на этом же сервере, расшариваются с помощью samba (сборка 3.2.3-3mdv2009.0, проверялось также на 3.3.1) Модуль etercifs версии 4.1.1 из сборки wine 1.0.9 network настройки samba следующие : [global] security = user case sensitive=no preserve case = yes short preserve case =yes default case = lower # проверялись различные комбинации относящиеся к case ..... [1c] guest ok = yes blocking locks = yes locking = yes oplocks = no level2 oplocks = no strict locking = yes share modes = yes fake oplocks = no delete readonly = yes read only = no path = /xxx/1c force user = nobody force group = nobody force directory mode = 0770 force create mode = 0770 create mask = 0770 directory mask = 0770 Костыль в исходник самбы временно решил эту проблему (smbd/filename.c): SET_STAT_INVALID(*pst); + + conn->case_sensitive=false; + conn->case_preserve=true; + conn->short_case_preserve=true; + *pp_conv_path = NULL; if(pp_saved_last_component) { *pp_saved_last_component = NULL; }
> диск монтируется в папку > пользователя ~/1c cледующим образом: mount -t cifs > -o > gid=x,uid=x,rw,noperm,nocase,iocharset=utf8,codepage=cp866,ip=xxx.xxx.xxx.xxx > //xxxxx/1c ~/1c > [global] > security = user > case sensitive=no > preserve case = yes > short preserve case =yes > default case = lower Я бы первым делом попробовал вообще не указывать параметры case sensitive, short preserve case и preserve case и в параметрах монтирования убрать nocase.
Я бы понял, что так и надо сделать, если это не работало бы под smbfs и с именами папок. Нужно чтобы работая в терминальных сессиях в линуксе у пользователей небыло возможности создавать файлы которые невозможно прочитать из сесий по Windows и запускалась 1С. Пробовал отключать все параметры, результат такойже - Ошибка загрузки метаданных. На всяческие варианты убил целую ночь.
Я воспроизвел вашу ситуацию и на Мандриве (причем на обычном драйвере cifs, а не etercifs) и на ALTLinux, причем как на вашей конфигурации самбы, так и на более простой конфигурации. Могу с уверенностью сказать, что на описанную вами ситуацию влияет только один параметр монтирования - nocase. Если все остальные параметры оставить как есть, а менять только его, то директория либо создается, либо нет. В man mount.cifs сказано, что параметр nocase - Request case insensitive path name matching. Так что эта документированная особенность mount.cifs никакого отношения к проблемам etercifs не имеет.
Получается что проблема не решена =(, без nocase и с параметрами в самбе по умолчанию результат такойже -> 1С не запускается. Уточнения (моя вина): Если создать базу c 0 из Linux то всё работает (1но - в какомто из случаев в мониторе при активных пользователях никого не видно), но если базы старые созданные/перенесённые/etc. из под Windows/других офисов/Novel/etc. то результат отрицательный == в виндовсе работают, в линуксе нет. Имя файла на диске 1cv7.md, 1C же пробует открыть 1Cv7.MD на что получает NT_STATUS_NOT_FOUND при любых case/nocase и любых настройках самой самбы. При принудельном указании sambe (up patch), всё работает но это помоему не выход. P.S. Имена папок меня интересуют меньше всего, просто они видут себя так как и требуется параметрами при монтировании и в самбе (Request case insensitive path name matching - ни одного упоминания про то что это влият только на имя папки я не вижу здесь). P.P.S. Соглашусь что это проблема не EterCIFS, но вроде как Etersoft гарантирует работу протестированных приложений во всяком случая работу 1С V7.7 и 1C V8
Wine предполагает, что файлы хранятся на регистро-чувствительной файловой системе, поэтому обычно он их проверяет через fstat, и если не находит, ищет перебором файлов в каталоге. Проблема может возникнуть только при ошибке в системе, когда fstat говорит, что файл есть, а open потом открыть его не может. Что выводит команда $ winelocktest при запуске на смонтированном ресурсе?
> Соглашусь что это проблема не EterCIFS, но > вроде как Etersoft гарантирует работу > протестированных приложений во всяком > случая работу 1С V7.7 и 1C V8 Ошибки в ядре, SAMBA, памяти компьютера к этой гарантии не относятся. Хотя, безусловно, мы постараемся проблему уточнить и закрыть.
Выводит такоеже как и lock-standard.txt С блокировками всё OK и если имена файлов такие как ожидает 1C то всё работает на "ура". Проблемы с открытием файлов в случаях описаных выше. Сейчас народ работает и под линуксом и под виндовсом, этих проблем не возникает (после патча).
Я так и не понял, есть ли проблема, если не монтировать с параметром nocase и не включать case sensitivity = yes и прочее в smb.conf.
БЕЗ НАЛОЖЕННОГО ПАТЧА, конечно есть.
Кстати, etercifs надо использовать 4.3.6, другие версии содержат ошибки. Мы можем попробовать вашу ситуацию на Mandriva 2009.1, но я сомневаюсь, что нам удасться её воспроизвести.
(In reply to comment #8) > Я так и не понял, есть ли проблема, если не > монтировать с параметром nocase и не включать > case sensitivity = yes и прочее в smb.conf. > Нет, конечно. (In reply to comment #10) > Кстати, etercifs надо использовать 4.3.6, другие > версии содержат ошибки. > Мы можем попробовать вашу ситуацию на Mandriva > 2009.1, но я сомневаюсь, что нам удасться её > воспроизвести. > Я уже это воспроизводил: http://bugs.etersoft.ru/show_bug.cgi?id=3655#c3 И выводы свои написал там же.
(In reply to comment #11) > Я уже это воспроизводил: Самбу, конечно, не патчил. Но проблему видел с nocase.
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.