midnight commander не умеет сразу удалять файлы при переносе по F6

2. умеют ли другие коммандеры (Gnome Commander или Double Commander) переносить правильно?

Подход mc не такой уж и неправильный: сначала полностью переместить всё, и только если в процессе не возникло ошибок, и не была произведена отмена, удалить источник. Иначе жмёшь на отмену - а получаешь два каталога с разным наполнением. В лучшем случае, в худшем - кое-какого файла нет уже ни там, ни там.

Интересно. Можно подробнее: переносим именно каталог или заходим в него, всё выделяем и переносим?

А если это происходит в одной фс, разделе?

Я гуглил проблему, и меня сбила с толку старая тема от балансера.

Но в моём случае сегодня, похоже, проблема была в том, что раздел после аварийной перезагрузки смонтировался в режиме «readonly», и даже под root'ом файлы при переносе не удалялись...

Сейчас я уже не уверен, что это была проблема mc.

Вобщем, я ещё раз перезагрузился и ещё раз зарядил F6 - понаблюдаю.

UPD. Нет - проверил, mc действительно не удаляет файлы по мере копирования!

Да, такое поведение и есть. В смысле это секрет какой-то что ли? Там же когда переносишь 100000000 файлов, сначала рисует прогрессбар и написаны имена файлов. А потом в конце написано «Удаление файлов» и снова бегут их имена.

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

Если я хочу так, как ты говоришь, то я сначала скопирую по F5, а потом удалю по F8 - нормальный перенос по F6 должен удалять по мере переноса.

mc ваще какой-то н0рком@н писал.

Капитан Очевидность просил передать, что логика переноса сильно зависит от того, переносятся ли файлы в рамках одной ФС или разных.

Если разных — почему ты считаешь, что правильный именно тот подход, который ты ожидаешь?

Потому что:
1) все предыдущие коммандеры (nc, vc, far) делали именно так
2) это логика здорового человека (вне зависимости от того, разные ФС или одна).

Ещё раз повторяю: если бы я хотел перестраховаться, то делал бы последовательно F5 и F8, а не F6.

это логика здорового человека

Блин.

Я тут хотел в предыдущий комментарий добавить простыню, сравнивающую достоинства и недостатки обоих подходов, но похоже, не в коня корм.

Попробуй не считать «логикой здорового человека» только ту, что нравится твоему внутреннему утёнку, а все остальные считать наркоманскими.

Гаврила переноской занимался
Гаврила файлы ворошил

Ведь файл такая хитрая штука
Что после переноса остаётся, … гхм, нехорошая такая

И нужно после переноса
Удалять его без спроса.

Опция в Настройках «удалять по ходу переноса» исключила бы любые споры, но автор-наркоман-mc не предоставил нам выбора.

Автор хорошей программы, которой ты пользуешься и тут же на неё наезжаешь, не обещал тебе, что сделает точно так же, как в любимом Волков Коммандере. Напиши feature request, хотя бы.

// Авторов, вообще-то, за долгую историю mc сменилось довольно много.

автор-наркоман-mc не предоставил нам выбора.

А наркоман ТС не предоставил авторам mc патч, реализующий данное поведение.

Это Opensource, детка. Здесь никто никому ничего не должен. Но если ты называешь кого-то наркоманом - будь готов предъявить документы^W патчи :-)

И нет, я к разработке mc не имею АБСОЛЮТНО никакого отношения

все предыдущие коммандеры (nc, vc, far)

Оргументы – агонь!

Это не в mc такое поведение, а в mv:

$ mv -v /tmp/test_mc/1 /tmp/test/
создан каталог '/tmp/test/1'
скопирован '/tmp/test_mc/1/test2.tmp' -> '/tmp/test/1/test2.tmp'
скопирован '/tmp/test_mc/1/test1.tmp' -> '/tmp/test/1/test1.tmp'
удалён '/tmp/test_mc/1/test2.tmp'
удалён '/tmp/test_mc/1/test1.tmp'
удалён каталог '/tmp/test_mc/1'

Если в одной фс (btrfs):

$ mv -v /tmp/test/2 /tmp/test/1/
переименован '/tmp/test/2' -> '/tmp/test/1/2'

наверное примонтировано что-то в подкаталог

Что после переноса остаётся,

shit?

есть ли какая-то настройка в mc, которая включает правильный перенос?

Настройка одновременно и существует, и нет.
Есть флаг, который меняет поведение, но он всегда устанавливается в одно значение, и поменять его из конфига нельзя. Изменяется только пересборкой.

--- a/src/filemanager/fileopctx.c
+++ b/src/filemanager/fileopctx.c
@@ -80,7 +80,7 @@ file_op_context_new (FileOperation op)
     ctx->preserve = TRUE;
     ctx->preserve_uidgid = (geteuid () == 0);
     ctx->umask_kill = 0777777;
-    ctx->erase_at_end = TRUE;
+    ctx->erase_at_end = FALSE;
     ctx->skip_all = FALSE;
 
     return ctx;

Даже досовские nc и vc удаляли файлы по мере переноса!

И зверски тормозили из-за этого.

тупой mc сначала копирует всё содержимое на новое место, а только потом в конце удаляет файлы и подкаталоги на старом месте.

Почему ты считаешь себя умнее других? В MC сделали оба варианта, и понятный тебе, и не понятный. Но почему-то остановились на непонятном тебе. Не пытался задуматься, нет ли тут какой причины?

доколе?!

Ну тут вообще всё очевидно. Пришла пора тебе писать свой файловый менеджер!

И зверски тормозили из-за этого.

Норкоман?

Нормальный перенос делает mv в рамках одной фс. В противном случае именно сначала cp, потом rm и никак иначе.

должен

Нихера тебе никто не должен, поц.

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

именно сначала cp, потом rm и никак иначе.

Это в рамках одного файла. Речь про дерево файлов.

все предыдущие перечисленные вами командеры делали это в рамках одной файловой системы

Ты норкоман?

Ты потерялся и ищешь своих? Ко всем с одним и тем же вопросом пристаёшь.

Не увиливай от ответа.

удваиваю! именно сначала копировать, а только после удачного копирования удалят более грамотно с точки зрения сохранности файлов

ТС-наркоман не осилил сосноль, но хает единственную софтину, с которой у него хоть что-то получается. Я правильно понял суть топика?

Изменяется только пересборкой.
ctx->erase_at_end = FALSE;

Хоть кто-то ответил по делу!
(ЛОР не безнадёжен)

Пассажирам бронепоезда ещё раз: если бы я хотел перестраховаться, то делал бы последовательно F5 и F8, а не F6.

И да, удаление сразу никоим образом не приведёт к пропаже файла, т.к. он удаляется после того, как оказался на новом месте.

UPD. Скачал сырцы, перекомпилял. Буду посмотреть. Спасибо!

Это не в mc такое поведение, а в mv

Во, кстати. Самый дельный комментарий в теме, наряду с ответом Рината, конечно. :)

автор-наркоман-mc не предоставил нам

что предоставил нам ты?

вообще-то, нет. Насколько мне известно, копирование и перемещение реализовано в mc «собственными силами», не вызывая mv

mc не использует mv

midnight commander не умеет сразу удалять файлы при переносе по F6 (комментарий)

Я тоже говорю про дерево. Есть такие понятния, как транзакционность и консистентность. Так вот, ТС про них нихера не знает. Нельзя делать rm, пока всё не скопированно без ошибок. Операция по идее или должна быть завершена полностью, или должен быть сделан откат на предыдущее состоянее. Если делать rm в процессе, то ты это самое состояние рано или поздно неизбежно просрёшь вместе с данными, поэтому вменяемые люди так и не делают. А агрумент, что вендовозы так делали всегда, ну так то ведновозы, что с них взять, у них при слове транзакционность тоже нечему шевелиться в голове.

И да, удаление сразу никоим образом не приведёт к пропаже файла, т.к. он удаляется после того, как оказался на новом месте.

Если у тебя копирование на фс валится с ошибками, то кто тебе гарантирует, что ты сможешь потом его оттуда прочитать, умник? Софт должен хорошо работать в большинстве кейсов, а не только в твоём.

Интересно, как оно себя поведет при перемещении в пределах одной ФС, но в условиях нехватки места для копирования.

Оно не будет ничего «копировать», кмк.

кмк

Воот. Но мне тоже лень проверять.

Ты всё правильно написал, с точки зрения подхода «надёжность, надёжность и ещё раз надёжность». Данные должны быть консистентны, это правильно.

Однако есть ещё разнообразные жизненные ситуации, когда копирование идёт УДРУЧАЮЩЕ МЕДЛЕННО, когда надо спасти с умирающего носителя всё, что ещё можно спасти и др. И с этой точки зрения ТС прав в желании видеть в mc галочку, позволяющую задать в mc режим переноса.

Неправ он, когда начинает объявлять желаемый режим «переносом здорового человека», а то, что сделано по умолчанию — «наркоманским» и орать «ПОЗОР».

Однако есть ещё разнообразные жизненные ситуации, когда копирование идёт УДРУЧАЮЩЕ МЕДЛЕННО

Если он *переносит* и делает rm в процессе как это поможет ему копировать быстрее? Единственынй кейс, это когда отменяешь по несколько раз копирование, а потом дописываешь.

когда надо спасти с умирающего носителя всё, что ещё можно спасти и др

Если носитель умирает оттуда вообще ничего нельзя удалять и вообще не должен быть в rw. Сделай c него dd, монтируй да делай потом что хочешь.

И с этой точки зрения ТС прав в желании видеть в mc галочку, позволяющую задать в mc режим переноса.

Но её никто не сделает, потому что, а зачем? Какие технические плюсы у такого подхода? Что-то там безответственно перетаскивать с лагающего накопителя через лагающую сеть на лагающий накопитель с перерывами на чай? Зачем вводить такую «галочку»? Ну ок, сегодня её ввели, завтра другой ТС просрёт так свои файлы.

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

Нет маленькой фс под рукой

dd && mkfs && mount.
Я проверил уже. Все работает, как с одиночным файлом, так и с каталогом.

просто ссылки меняются

Тут было сказано «тупой mc сначала копирует всё содержимое на новое место», мне стало интересно.
Я проверял МС от седьмого центоса, но не думаю, что он с тех пор сильно изменился.

Это Opensource, детка. Здесь никто никому ничего не должен. Но если ты называешь кого-то наркоманом - будь готов

Это Opensource, детка. Назвав кого-то наркоманом, ты не становишься ему должен.

Неважно использует или нет, но поведение аналогичное. Возможно, создатели mc опирались на поведение mv в реализации перемещения.

Возможно, но поведение вполне логичное и легко программируемое (сначала вызываем функцию копирования всего, потом удаления этого «всего»)

Пришла пора тебе писать свой файловый менеджер!

Свой mc писать не стал, запилил пул-реквест:
https://github.com/MidnightCommander/mc/pull/173/commits/c40f676dcdc33ad09497...

Если примут, теперь в mc появится человеческая настройка.

запилил пул-реквест

If erase_at_end is FALSE files will be deleted immediately after their successful copy (Note: this behavior is not tested and at the moment it can't be changed at runtime).

Не смутил коммент? Похоже, так уже пытались делать, но что-то помешало. Поэтому захардкодили TRUE.

На первый взгляд всё работает. Будем решать проблемы по мере поступления.