LINUX.ORG.RU
ФорумTalks

Почему в файловых менеджерах Linux так ущербно реализована функция перемещения файлов?


1

2

Выделяем кучу больших файлов и каталогов с большими файлами. Делаем «Вырезать» (если файловый менеджер не имеет команды «Переместить»), переходим в другой каталог на ТОМ ЖЕ разделе. Выбираем «Вставить». И что мы получаем? Вместо мгновенного перемещения файлов (ну или почти мгновенного - если файлов совсем много, нужно время рекурсивно обойти все выбранные каталоги) этот процесс может растянутся на несколько часов (и в это время система, разумеется, будет подтормаживать из-за активного дискового I/O). Почему так происходит? Потому что какой-то альтернативно одарённый человек решил, что просто переместить файл средствами ФС некошерно - надо сначала скопировать файл, а потом удалить оригинал. Это можно понять, когда приёмник и источник на разных ФС - тут иначе никак, но зачем так делать, когда ФС одна и та же???

Так делает и Nautilus, и Dolphin, и даже Midnight Commander (на него я возлагал свои последние надежды). А вот команда mv (хоть рекурсивная на кучу каталогов с кучей файлов) выполняется практически мгновенно, но использовать её не всегда удобно.

Кто-нибудь, объясните мне, почему ни в одном файловом менеджере авторам не хватило ума поставить простое условие «Если (ЦелеваяФс == ИсходнаяФс) То ПереместитьФайл; Иначе СкопироватьФайл; УдалитьФайл; Конец». Не верю, что это настолько сложно (mv же делает как-то), даже скорее всего есть готовая функция libc/системный вызов ядра, который сам решает копировать или перемещать.

★★★★★

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

Просто удивляюсь, откуда такой имидж у Арча

у меня нет точной статистики, но типовой местный арчевод действует по такой схеме:

  • ставит арч и всем рассказывает, что доволен как слон, ничего не отваливается после апдейтов уже неделю(месяц, и т.д.)
  • постит скриншотик с опенбоксом в галерейку
  • создает нытик-тред в толксах об «удачном» апдейте

за что и любимы местными троллями

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

Прямо сейчас перестала работать система, потому что /bin/systemd теперь /ust/lib/systemd/systemd. Да, тоже чейнджлоги не читал.

Вручную настраивал загрузчик — вручную и перенастроишь. Всё логично.

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

Непонятно, вообще нахрена они все таскают туда-сюда. Три года этому systemd, а Леннарт все решить не может, где что должно лежать. Да еще и бинарники в либы кладет. Defective by design, в общем.

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

Читай FHS, прежде чем писать ерунду.

/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts.

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

О, точно. Зря я на systemd грешил. Оно там с 41 версии. В общем-то, при переходе на systemd на вики арча было написано вписать в загрузчик именно init=/bin/systemd. А сейчас они этот симлинк зачем-то решили удалить, и написали об этом только в выхлопе пэкмена, который я потерял в куче остального выхлопа.

keyran ★★
()

И что мы получаем? Вместо мгновенного перемещения файлов (ну или почти мгновенного - если файлов совсем много, нужно время рекурсивно обойти все выбранные каталоги) этот процесс может растянутся на несколько часов (и в это время система, разумеется, будет подтормаживать из-за активного дискового I/O).

Это когда так было? Я с ntfs на ntfs копировал, и потом с ntfs на ext4 объёмами от 300 до 500 гигабайт - никаких тормозов не было. Перемещал до 50 гигов, больших объёмов не помню.

Может ФС?

ekzotech ★★★★
()

Так делает и Nautilus, и Dolphin, и даже Midnight Commander (на него я возлагал свои последние надежды).

Если в пределах одного раздела, то MC делает это быстро.

andreyu ★★★★★
()

Так делает и Nautilus, и Dolphin

4.2. Рекурсивный обход - это, конечно, плохо, но копии файлов не создаются.

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