"error 20005" при последовательном монтировании нескольких ресурсов

[unxed]

в момент установки соединения (smb, sftp).

при этом соединение всё равно устанавливается, то есть, если переоткрыть панель gvfs и попробовать "зайти" в ресурс - всё в порядке.

от чего зависит появление или не появление этой ошибки, я пока не понял. ищу.

[cycleg]

Скажу больше: бывают спонтанные падения без видимых причин и даже какие-то зацикливания. Из-за этого убрал автоматическое определение статусов ресурсов из процедуры загрузки плагина. Скучно лицезреть черное окно. Подозреваю засады где-то в GIO, ну или некое непонимание, как ею правильно пользоваться. Уже есть проблема #6, тоже какая-то противоестественная. Если бы кто-нибудь нашел примеры использования плюсовой gtkmm (не C-интерфейса! Про него есть исходники из Debian), было бы очень здорово.

[unxed]

Собственно, родные их мануалы, полагаю, можно не предлагать?

http://www.gtkmm.org/en/documentation.shtml

Навскидку:
https://github.com/darsto/gtkmm-examples
http://rus-linux.net/MyLDP/BOOKS/gtkmm/03-basics.html

Ещё, если есть учётка на хабре, можно постучаться в автора вот этого:
https://habrahabr.ru/post/145160/

[unxed]

Не знаю, важно это или нет, но заметил странность: после "error 20005" кидает в папку предыдущего ресурса, которым пользовался через плагин. Не того, в который пытаешься зайти, а предыдущего.

[unxed]

вот пример работы с gvfs в cpp и его обсуждение (можно, по идее, там попробовать в комментах задать вопросы):

http://stackoverflow.com/questions/25739391/mounting-samba-share-in-c

ещё пример работы с gvfs из плюсов:

https://sourceforge.net/p/lufs/svn/41/tree/trunk/lufs/filesystems/gvfs/gvfs.cpp?diff=51adf6752718464efaa5053d:40&diformat=sidebyside

и ещё пример:

https://docs.libreoffice.org/ucb/html/gio__content_8cxx_source.html

и ещё, кажется, в wx есть какая-то поддержка gvfs:

https://github.com/wxWidgets/wxWidgets/blob/master/src/gtk/gnome/gvfs.cpp

вообще, если гуглить "Gio::MountOperation::create();", кое-что найти можно.

[unxed]

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

[unxed]

чёткая инструкция, как воспроизвести 20005:

1. подмонтировать ресурс A
2. подмонтировать ресурс B
3. отмонтировать ресурс A
4. подмонтировать ресурс A
5. отмонтировать ресурс B
6. подмонтировать ресурс B
7. goto 3 (в пределах 10 итераций случается error 20005)

[unxed]

можно ещё проще: монтировать несколько ресурсов один за другим. рано или поздно (обычно на 2-4 ресурсе) случается 20005. то есть, отмонтирование не является обязательным фактором возникновения этой ошибки.

[cycleg]

Эта ошибка появляется "со стороны" far. Он подключает ресурс на контроль (типа, чтобы извещения об изменениях видеть, но с нелокальными файловыми системами это не работает; во всяком случае, с farftp та же песня), но там возникает некая ошибка при попытке извлечь метаданные из файловой системы. Причем в лог валится что-то типа "TODO: decode error 5". А ресурс в это время уже подмонтирован, на самом деле. И совершенно справедливо отобразится на панели как подмонтированный. Такое впечатление, что там gvfs "не догоняет", не успевает подготовиться к какому-то системному вызову. Поэтому и ошибка всплывает далеко не всегда.

Примеры все на C. Про такие исходники писано было сразу. Архитектура довольно зверская: в glib есть так называемые C-классы, что называется, "закат солнца вручную", когда разработчик прикидывается компилятором и делает часть его работы. Поверх них есть обертка C++, в которой своей функциональности почти нет. Однако, эта прослойка таки добавляет багов, очевидно. Ибо C-интерфейс и его вызовы работают нормально, что видно на примере того же gvfs-mount.

Проявилась еще одна особенность: если связь прервалась, то ресурс остается какое-то время подмонтированным (на тайм-аутах транспортного протокола висит?). Спрашиваешь у GVFS: есть такой mount? Не моргнув глазом, отвечает: есть! И только попытка отмонтировать показывает, что mount уже протух. Если сразу попытаться смонтировать заново, выдает волшебную ошибку: сервис с именем ":<число>" не известен. Число с виду очень похоже на какой-то интервал времени от секунды до полутора. Откуда, из какого пальца это высасывается, если на вход подаешь тот же URL? Вторая попытка будет уже удачной (ну если связь есть). В общем, странностей в работе GVFS хватает.

[unxed]

не успевает подготовиться к какому-то системному вызову

Вот у меня тоже сложилось впечатление, что проявление ошибки зависит от скорости монтирования ресурса (скажем, с роутером на openwrt sftp-соединение устанавливается довольно долго, и на нём ошибка возникает, кажется, чаще), но точную зависимость выявить пока не удалось, вот и не стал об этом писать.

И только попытка отмонтировать показывает, что mount уже протух.

Интересно, этот баг проявляется в консольном gvfs-mount? Т.е. это тоже баг лишнего уровня абстракции, или реализации?

[cycleg]

Феерический комментарий в исходниках glibmm (mountoperation.hg, строка 75):

//TODO: We really need some test to make sure that our use of ArrayHandler is correct. murrayc.
#m4 _CONVERSION(const std::vector<Glib::ustring>&',const gchar**',`const_cast<const gchar**>(Glib::ArrayHandlerGlib::ustring::vector_to_array($3).data())')

#m4 _CONVERSION(const gchar**',const std::vectorGlib::ustring&',`Glib::ArrayHandlerGlib::ustring::array_to_vector($3, Glib::OWNERSHIP_DEEP)')
_WRAP_SIGNAL(void ask_question(const Glib::ustring& message, const std::vectorGlib::ustring& choices), ask_question)

Все-таки косяк где-то там.