LINUX.ORG.RU

Libreoffice bug? Просьба подтвердить или опровергнуть.

 ,


2

2

Ситуация:
- Установленный Debian на двух клиентских машинах.
- Подключениый по mount.cifs протоколу каталог с сервера(в данном случае windows, но должно быть без разницы)
- Одновременное обращение к одному файлу(тестирован вариант doc,docx,odt)
При стандартной настройке идет полная блокировка файлы(другим нет ни чтения, ни записи).
Попросили сделать как в «windows», т.е. если один открыл, то другие могут открыть, но только «на чтение».
Нашел совет как сделать это на linux.
=================== НЕ ХОРОШИЙ СОВЕТ(на текущее время) =======
Меню «Сервис/Параметры» выбираем «Libreoffice/Расширенные возможности» и нажимаем кнопку «Открыть Экспертные настройки»
На английском это «Tools/Options/Advanced/Open Expert configuration»

Набираем в поиске «UseDocumentSystemFileLocking» , ищем и устанавливаем значение «false».
==============================================================
Следуя совету - получилось открыть у второго пользователя, НО ЕСТЬ ГЛЮК.
Последовательность действий:
USER_1 открыл документ /mnt/SERVER/XXX.(doc,docx,odt) на редактирование.
USER_2 следом открыл документ /mnt/SERVER/XXX.(doc,docx,odt) на чтение.
USER_2 прочел документ и закрыл.
USER_1 изменил документ и пытается сохранить(выдается сообщение «нет файла»). В файловом менеджере файл /mnt/SERVER/XXX.(doc,docx,odt) - виден.
USER_1 отменил изменения и закрыл libreoffice. Файл /mnt/SERVER/XXX.(doc,docx,odt) - отсутствует, т.е. удален !!!!

Проверили многократно, повторяется 100%.
Может кто у себя проверить, и если хорошо знает english запостить багу?

Предупреждение: USER_1 был за своим компом, а USER_2 был за своим компом(т.е. компы клиентов разные).

P.S. поиск по багам ( https://bugs.documentfoundation.org/buglist.cgi?quicksearch=UseDocumentSystem... ) - схожего (удаление файла) не находит.

★★★★★

лучше бы тебе самому написать, проблемы с файлами на сетевых каталогах у Либры есть, это точно. Просто если я напишу багу по твоему описанию, а с меня попросят проверить что-нибудь в твоём окружении, я конечно не смогу.

Не стесняйся юзать гугл транслятор, если не уверен в своем английском

Kompilainenn ★★★★★ ()
Ответ на: комментарий от Kompilainenn

в данном случае я скорее хотел попросить у других по тестировать. Если подтвердится можно тогда оформить багу.

Atlant ★★★★★ ()

Файл /mnt/SERVER/XXX.(doc,docx,odt) - отсутствует, т.е. удален !!!!

Эпично. Надеюсь, ты зарепортишь, и это починят.

wandrien ()

Какой-то очень странный юзкейс использовать обычное офисное приложение, не предназначенные для совместной работы с документами для редактирования расшаренных файлов.

xmikex ★★★★ ()
Ответ на: комментарий от xmikex

что за бред. Это один из самых распространенных юзкейсов в офисах: держать доки на расшаренном каталоге на сервере (надеюсь понятно, для чего?), а открывать их со своих локальных машин. Конечно, кто первый открыл, тот и имеет полный доступ, а остальным можно и нужно давать права только для чтения. Почему у ТС этого не происходит - это вопрос №1, почему файл сносится молча после его манипуляций - это вопрос №2.

Кстати, ТС, какая версию Либры-то?

Kompilainenn ★★★★★ ()
Ответ на: комментарий от Atlant

Можно оформить репорт и так, ты думаешь кто-то тут будет заморачиваться и тратить день на эксперименты? Когда можно просто котиков поглядеть в сети?

Kompilainenn ★★★★★ ()

Одновременное обращение к одному файлу(тестирован вариант doc,docx,odt)

Так нельзя делать. И шары такие нельзя делать. Вся «проблема» это «ой, пацаны, я хочу сделать шару с конкурентным доступом через жопу, у меня ничего не выходит».

crutch_master ★★★★★ ()
Ответ на: комментарий от Kompilainenn

Это не может быть багом либры, только самой cifs.
Для приложения должна быть прозрачна работа файловой системы - оно просто открывает и закрывает файл.

xmikex ★★★★ ()
Ответ на: комментарий от fornlr

через GVFS?

Через него не пробовал. Тут скорее другие баги пойдут. Но будет время, попробую.

Atlant ★★★★★ ()
Ответ на: комментарий от Kompilainenn

не помню сейчас, но точно недавно(неделю назад где то) обновленный дебиан без сторонних источников(repos).

Atlant ★★★★★ ()
Ответ на: удаленный комментарий

Разработчики офисных пакетов могли бы и такую ситуацию предусмотреть. Почему бы и нет? Неужели не смогут осилить синхронизацию редактирования документов через временный файл?

Leupold_cat ★★★★ ()
Последнее исправление: Leupold_cat (всего исправлений: 2)
Ответ на: комментарий от Leupold_cat

Почему бы и нет?

Дело в том, что «сетевые» ФС не предназначены для таких кульбитов. Чтобы всё нормально синхронизировалось делают специальное серверное ПО с очередями, блокировками, кэшами, логами транзакций и чёртовой матерью.

Неужели не смогут осилить синхронизацию редактирования документов через временный файл?

С сетью и состоянием фс в момент синхронизации может происходить что угодно. Чтобы это стабильно работало, надо добавлять кучу всего, чему в фс не место.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: удаленный комментарий

А что ты предлагаешь делать в случае необходимости иметь общие файлы, которые один редактирует, а все остальные должны иметь возможность читать его? Какие есть правильные решения?

Entmatix ()

Как уже сказали, в либре хватает багов при работе с шарами. Уже лет десять баг с функцией автобекапа файла. Если в настройках либры включена опция автобекапа файла (бекапает в хомяк пользователя в директорию настроек либры), то при попытке сохранить открытый на шаре файл либра тебе выплюнет ошибку и ничего не сохранит. Можно только задать путь сохранения вручную (сохранить как), но не на самбе. Как автобекап в хомяке пользователя препятствует сохранению файла в шаре остается только догадываться.

Entmatix ()

Добавлю себе тему в избранное. Хочется поучаствовать в фиксе, но критически нет времени.

wandrien ()
Ответ на: комментарий от Entmatix

которые один редактирует, а все остальные должны иметь возможность читать его? Какие есть правильные решения?

Пусть хотя бы скидывает себе на комп да локально редактирует. Как минимум будет одна резервная копия. Правда делать так никто не будет и рано или поздно они обязательно похерят что-нибудь важное. Не с багами LO, так другим способом. Основываюсь на опыте работы с шарой ведны + mso, если что.

Какие есть правильные решения?

Более-менее нормальное решение - облако. Можно, конечно, выплясывать с самбой, приделывать туда версионирование, квоты, защиты от шифровальщиков, но надо ли? Облако лучше, т.к. с одной стороны уже на входе даёт больше возможностей по контролю всё этой помойки, чем «папочка», с другой урезает возможности так, чтобы не провоцировать юзеров тащить в облако весь свой хлам.

crutch_master ★★★★★ ()
Ответ на: комментарий от wandrien

Поучаствуй. Когда припрут еще вагон подобных багов, поправь и их, раз время так дохера. Когда-нибудь до них дойдёт (или это станет модным) и они сделают сервер с документами + интеграцию. Лет через 50 может быть, прикрутят еще и p2p, чтобы всё было serverless и zeroconfig если проект не сдохнет от ненужности раньше.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Я никого не игнорю принципиально. И в особенности не игнорю тех, кого надо репортить на постоянной основе и снимать звёзды, а в перспективе - банить за систематический тупак и флуд в техразделах.

wandrien ()
Ответ на: комментарий от wandrien

Я никого не игнорю принципиально. И в особенности не игнорю тех, кого надо репортить на постоянной основе и снимать звёзды, а в перспективе - банить за систематический тупак и флуд в техразделах.

На мой взгляд, это самое адекватное отношение к механизму игнора в текущем виде.

Только я бы пошёл дальше и ввёл бы механизм, позволяющий любому пользователю проверить, У КОГО он в игноре. Одностороннее облегчение жизни для одной части форума (раз уж оно есть) не должно сопровождаться затруднениями для другой.

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от wandrien

банить за систематический тупак и флуд в техразделах

Любители самба-шар не виноваты. Их так научили, они и делают. Бесперспективность этого подхода даже сами его архитекторы не сразу поняли.

crutch_master ★★★★★ ()
Ответ на: комментарий от crutch_master

специальное серверное ПО с очередями, блокировками, кэшами, логами транзакций и чёртовой матерью.

Как я понимаю, CIFS+Sharepoint это умеют, логично, что самба не умеет.

Shadow ★★★★★ ()
Ответ на: комментарий от xmikex

Это не может быть багом либры, только самой cifs.

Для приложения должна быть прозрачна работа файловой системы - оно просто открывает и закрывает файл.

А вот с этим я согласен. Кстати, с виндовыми шарами на виндовых серваках такой проблемы с Либрой я не наблюдаю

Kompilainenn ★★★★★ ()
Ответ на: комментарий от Atlant

обновленный дебиан без сторонних источников(repos).

вангую безумно старую версию LibreOffice, типа 6.0 >_<

Обновиться бы вам по поводу офиса, на актуальную 7.1.7, например

Kompilainenn ★★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.