LINUX.ORG.RU

Зависание файловых менеджеров на сетевых дисках

 


0

1

Если скорость копирования/чтения на сетевой диск низкая, то файловые менеджеры зависают. Причем в случае с Spacefm зависает не только окно с открытым сетевым диском, но и другие окна, а также его рабочий стол ~spacefm --desktop Есть ли решение этой проблемы ?

Ответ на: комментарий от anonymous

Это ты ещё несетевых флэшек не видел, там вся система зависает.

Забыл сказать, что зависание также есть на примонтированных через ptp фотоаппаратах и андроид через mtp. Это если в открытом каталоге большой фильм, а в фм включены превьюшки.

UriyZenkov
() автор топика

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

UriyZenkov
() автор топика

А когда таким образом зависает ФМ, то ты сидишь за компом без рук. Надо открыть каталог, получить доступ к файлов, а файловый менеджер нельзя ни запустить заново ни вырубить командой killall -s 9. В крайнем случае перезагрузить компьютер, тут хорошо что у меня инит не Systemd а, Systemv, ибо пришлось бы три часа ждать перезагрузки. Остается только принудительно вырубить сетевой диск командой umount -l или выдернуть сетевой кабель. Можно конечно установить другой ФМ для подобных случаев, но устанавливать дополнительный ФМ специально для того момента, когда основной завис и не реагирует на killall -s 9, сами понимаете — смешно. Я понимаю, что ФМ в таких случаях на самом деле не зависает, а всего лишь настолько внимательно ждет ответов от удаленного хоста, что даже не обращает внимание ни на что другое. Но можно же решить эту проблему ?

UriyZenkov
() автор топика

Для редкоземельных FM никому не интересно исправлять вот такие неочевидные ошибки.

Тут либо пердолиться во все дыры, либо использовать самое попсовое решение Nautilus+GVFS

хорошо что у меня инит не Systemd а, Systemv

Хотя ты и сам видать не прочь попердолится... Ну так чего ныть тогда.

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

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

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

Непонятно тогда, откуда такие проблемы. Если монтировать через GVFS, то ничего не зависнет. С FUSE посложнее, но там до перезагрузки довести дело - надо очень постараться.

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

Собственно, научились - есть FUSE. Он гибкий, но медленный. Зато позволяет делать всякую дичь вроде sshfs, ftpfs, nullfs, и т.д. И стрелять в отличии от ядерных можно (если потери данных не боишься).

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

файловые менеджеры зависают

никому не интересно исправлять

И в самом деле. В Проводнике всё работает.

Deleted
()

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

Ах да, при этом даже очень древние версии винды такими проблемами не страдают.

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

Ах да, при этом даже очень древние версии винды такими проблемами не страдают.

Зато свежие страдают.

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

Значит испортили винду, я в последний раз на 8.1 (или просто 8?) проверял, там все хорошо работало. На самом деле, в некоторых файловых менеджерах под линукс эту проблему кое-как исправили, после того, как я на нее указал, но не до конца и костыльно.

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

Значит испортили винду

А ты больше «линуксоидов» слушай — подумаешь, что и открыть файловый менеджер без БСОДа не получится.

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

Практически любые графические. pcmanfm, thunar, nautilus, dolphin, krusader, плюс еще пару редкоземельных проверял, но уже не помню какие. Все тупили тупили до неюзабельности на каталогах с большим количеством файлов, не сдавался только mc и еще какой-то двухпанельник на уродливом тулките, названия которого, я конечно же, не запомнил. По каким-то из них даже движуха в баг-трекерах была, но сейчас я точно проверить не могу, т.к. с тех пор сменил работу и у меня теперь тупо нет столько файлов под рукой.

anonymous
()

Человек в здравом уме не использует линукс на десктопе.

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

Это с включенными превьюшками или без ? А на винде превьюшки были включены ? А сейчас каким ФМ/и или ОС пользуетесь ?

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

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

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

А как по скорости открытия каталогов в линуксе и винде ?

UriyZenkov
() автор топика
Ответ на: комментарий от anonymous

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

Интересно, а какие это ?

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

В кдешном dolphin точно закостылен хардкод, который автоматическ начинает сортировать файлы другим способом, чем ожидается, если количество файлов больше какого-то захардкоженного числа. Зато многопоток. А еще в какой-то файловый менеджер (вот уж не помню, то ли thunar, то ли еще что-то) запилили возможность выбирать алгоритм сортировки в настройках. Типа, выбирай сам, что тебе нужно, скорость или функциональность.

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

В смысле ? На какую систему ?

На ту, у которой FUSE в ядре.

iZEN ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.