А он сначала режет, а потом считает.

Это шикарно :)

Именно поэтому разработчики решили перейти на Qt.

qt то здесь при чём ?
или ты считаешь, что из-за gtk оно так себя ведёт
в моём thunar такого нет,хоть он и на gtk

Я только что шикарный пост прочитал. Человек переносил файлы с флешки на внешний винт, винт внезапно оказался примонтирован read-only. Человек из-за бага потерял файлы. Что делает в этом случае банальный пользователь софта? Создаёт баг-репорт с пометкой «grave — causes data loss». Что делает этот человек? Пишет пост на локальный форум. Я в замешательстве.

Интересно, хочет ли он, чтобы баг был исправлен? И что он для этого сделал?

P.S. А ведь был уже такой баг, в 2010-м.

Ну не знаю, если б я наткнулся на такой баг, я бы не стал отсылать никакие репорты, а просто снёс бы это поделие нахер.

P.S. А ведь был уже такой баг, в 2010-м.

какие же терпеливые пользователи у этого поделия.

типичная потреблядь

Ну не знаю, если б я наткнулся на такой баг, я бы не стал отсылать никакие репорты, а просто снёс бы это поделие нахер.

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

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

Меня устраивает, описанная в ОП проблема ни разу не задевала.

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

[к.о.] идиоты. [/к.о.]

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

Лично у меня после 1-2к строк случается «я больше не помню, что и как работает». Поэтому вполне понимаю, как такое могло случиться — ну никак нельзя продумать всё. Если долго смотришь на свой код, глаз замыливается, и такого просто не замечаешь. Это не простая опечатка, которую легко отловил бы компилятор.

Либо ты сам не пишешь код, либо ты гений, который пишет идеальный код без ошибок с первого раза (и тогда тебя не существует).

Поэтому в Debian, понимая невозможность исправления этой ошибки без обновления до довольно бажной версии 1.1, обошли её, чтобы пользователи не теряли свои данные. Enjoy your Ubuntu.

вполне понимаю, как такое могло случиться

А я не понимаю. Это настолько детский баг, что просто диву даюсь.

намного интереснее, как они умудрились повторить его во второй раз

А я не понимаю. Это настолько детский баг, что просто диву даюсь.

Аватарка соответствует, да.

Это настолько детский баг

Можно пример не детского бага? Мне интересно аж стало.

Можно пример не детского бага?

Можно.

Можно пример не детского бага?

Можно.

То есть конкретного примера нет?

Нет.

Дело было на 10.04ой лубунте, так что скорее всего это тот самый баг, который уже давно починили. Пост писал под впечатлением. Да, кстати, а почему пост на форуме исключает багрепорт?

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

Да, кстати, а почему пост на форуме исключает багрепорт?

Ну погорячился я.

Эпик фэйл

Идеальных нет.

Ну не знаю, вот пробовал я когда-то давно yi, открыл некий исходник - отвалилось, дихотомией выяснил, что из-за юникодного (c).
Сразу снес (впрочем мелькнула мысль, что репорт уже вероятно есть) и забыл до следующей версии.

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

Все толстовато тролль, особенно вкупе с ником.

Что не так с его ником?

если б я наткнулся на такой баг, я бы не стал отсылать никакие репорты, а просто снёс бы это поделие нахер.

Вот поэтому всем разработчикам Open Source следует самим включать проверки в код, а не надеяться на Иудушку Головлева за компом.

Да, тоже несколько говнях в виде «лёгких фм» сравнивал, все с таким результатом. Только nautilus(gnome) и dolphin(kde) рабочие.

Пока разработчики Open Source собирались включать проверки весь остальной мир давно использовал исключения.

Да как угодно.

Такое багрепортить бессмысленно. Если разрабы это сделали - они эпичные идиоты. Прогу нужно выбрасывать сразу. Мало ли чего они там еще набыдлокодили...

Какую ошибку? Ты о чем? Любые действия где удаляются данные, должны быть протестированы ДО выхода из альфы. Это перемещение файлов - одна из базовых функций ФМ и она удаляет данные. Она обязана быть идеальной!

Кстати, по подобным причинам я бессознательно избегаю пользоваться перемещением. Если нужно переместить - я сначала копирую, а потом удаляю источник.

Это настолько детский баг, что просто диву даюсь

Просто разработчик никогда не слышал про QA.

Что делает в этом случае банальный пользователь софта? Создаёт баг-репорт с пометкой «grave — causes data loss». Что делает этот человек? Пишет пост на локальный форум. Я в замешательстве

Факапы бывают у всех. Но особенно круто смотрятся 2 видов, когда разработчик пропускает ТАКИЕ баги и когда он ложит болт на баги, убеждая, что оно так задумывалось. Так было с qBittorrent, Opera. Проблема в головах, а не клозетах. Багрепорт на баг в генах разработчика Господу не напишешь. Поэтому я считаю, такой софт надо тупо забрасывать ко всем чертям.

++

Возможно это не баг, а просто пользователи клонов проводника должны страдать?

Какую ошибку? Ты о чем? Любые действия где удаляются данные, должны быть протестированы ДО выхода из альфы. Это перемещение файлов - одна из базовых функций ФМ и она удаляет данные. Она обязана быть идеальной!

В твоём мире, похоже, хорошо живётся, и никто не допускает глупых ошибок. Как в него попасть? Он мне нравится.