Board.KolibriOS.org

А что если я случайно накосячу?

Тогда вылезет автор программы и навешает виртуальных люлей...

trunk, как я понял - основная версия (в отличие от ответвлений)?

ЕМНИП для программ кроме trunk ничего не сделано, потому что нету таких крупных проектов, над которыми работают более 2-3 человек.

Dante wrote:Не могу удалить свой test.tmp.

Из командной строки это делается командой svn delete <filename> (она же del, remove, rm) с последующим svn commit для фиксации изменений. Как это делается в графическом клиенте, пусть ответят те, кто им пользуется.

Dante wrote:А что если я случайно накосячу?

Лучше не косячить. Но если что, найдётся, кому исправить. Кстати, на svn хранятся и все предыдущие версии всего, что туда было залито (svn up -r<ревизия>), так что откатить особого труда не представляет.

Dante wrote:trunk, как я понял - основная версия (в отличие от ответвлений)?

Для svn как такового это неважно, но есть общее соглашение: trunk - основная версия, tags - релизы, branches - ответвления. Типичное использование - trunk развивается непосредственно (главная линия разработки), tags хранит старые релизы, и иногда туда вносятся отдельные изменения из trunk (или независимые) в рамках поддержки старых версий, branches хранит переорганизуемую версию, которая прямо сейчас несовместима с trunk и/или вообще не работает, но в которой продолжаются изменения. Есть специальные средства для синхронизации изменений в разных папках одного проекта. Подробнее - в руководстве по svn, ссылка есть в статье на вики.

Вообще-то аккаунты выдаются не для того, чтобы мусорить на svn. Пять мусорных ревизий подряд - это как вообще понимать?
Update: за время написания поста уже шестая. Бан уже близко.

Созданный файл удалил, следующая мусорная ревизия приведёт к бану.

ИМХО пора откатывать.

Откатываются изменения, но не история. Из изменений там был один файл test.tmp в корне, который уже удалён, а история хранится, пока жив репозиторий.

KFar_Arc 0.17: пофиксена некорректная обработка некоторых архивов (иногда появлялись несуществующие файлы; спасибо Leency за предоставленный пример архива).
Исходники, как обычно, на svn, бинарники - в последней ночной сборке.

diamond, ты можешь экспортировать из плагина-распаковщика функции разжатия данных, упакованных по deflate? Этот метод применяется в zip, значит, он уже реализован. Я хочу добавить в downloader поддержку сжатия протокола HTTP. Я посмотрела на интерфейс плагинов - он предназначен для работы с файлами-архивами, а готовых функций для разжатия данных в нём нет.

CleverMouse
На самом деле распаковка deflate в экспортах kfar_arc уже есть (и даже используется, например, libimg при загрузке png), просто об этом нигде не написано. Залил документацию на svn.

Может уже кто-то про это говорил,но я хочу индикатор копирования файлов... Колибри - это моя единственная надежда спасти 120 гигабайт данных. Нтфс-диск, с которого данные может прочесть лишь Колибри - а другие ОС при попытке чтения с диска умирают

Sorcerer wrote:Может уже кто-то про это говорил,но я хочу индикатор копирования файлов...

Имеется ввиду прогресбар?

Sorcerer wrote:Колибри - это моя единственная надежда спасти 120 гигабайт данных. Нтфс-диск, с которого данные может прочесть лишь Колибри - а другие ОС при попытке чтения с диска умирают

Мне кажется в любом случае надо снять образ один в один со всего диска, чтобы количество попыток увеличить - кто его знает что другие реализации драйвера NTFS могут сделать (которые не в Колибри). Они ведь дату доступа к файлам тоже пытаются впаять, могут и попортить.

Mario, спасибо огроменное за KFM! Не знаю почему, но копирует он раз в 40-50 быстрее, чем KFAR
Правда, есть некоторые небольшие глюки - часть имен файлов превращается в кракозябры, а часть - нет. Плюс 2-3 файла из 4-5 тысяч не удалось скопировать. Версия 0.47b из старой ночной сборки, которая была под рукой на cd. Сейчас буду пробовать самую свежую ночную...
И еще одно - при подключенном bd-диске и отключенной мышке KFM (и eolite кстати сказать) падают, каждый раз с разными значениями регистров, а kfar - не падает.

Sorcerer

Mario, спасибо огроменное за KFM! Не знаю почему, но копирует он раз в 40-50 быстрее, чем KFAR

KFM копирует кусками по 1/4 от доступной памяти ОЗУ (ЕМНИП, но лучше код посмотреть, чтобы точно). За счет этого на больших файлах получается выигрыш, но есть и минус - дисковая система частично (в пределах одного физического устройства или одного контролера или одной файловой системы - драйверы то общие) в момент одного обращения к системе оказывается заблокированной. Чем продолжительнее обращение, тем большее время другие программы не могут получить доступ.

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

Ну, здесь вряд ли KFM виноват - он работает со стандартной структурой 70 функции. Что получил то и отдал. Однако ты же сам сказал, что структура данных битая - так что всякие "чудеса" имеют место быть.

Плюс 2-3 файла из 4-5 тысяч не удалось скопировать.

Опять же битая структура данных.

Версия 0.47b из старой ночной сборки, которая была под рукой на cd. Сейчас буду пробовать самую свежую ночную...

Разницы никакой - там поправлена только очистка регистра ESI при отрисовке окна.

И еще одно - при подключенном bd-диске и отключенной мышке KFM (и eolite кстати сказать) падают, каждый раз с разными значениями регистров, а kfar - не падает.

KFAR учитывает большее количество исключений и написан в целом более грамотно.

Мне кажется, что дело не в битой структуре. Я создаю десяток папок на диске FAT32 - из них часть с нормальными именами получается, а часть нет. Кажется, но не уверен, кракозябры выходят если я использую одновременно большие и маленькие буквы. В Колибри кстати все видится нормально...

Жалко, что нет рекурсивного копирования Но переживу 10 гиг самого нужного из 120 за ограниченное время работы спасено

Рекурсивное копирование я не реализовал по причине применения 64 функции. Логика кода получалась зверски сложной. Такую логику разве что SQL выражением записывают. Максимум на что хватило меня это рекурсивное удаление.

На момент написания KFM я понимал в программировании раза в 3 меньше, если разница не еще больше и переварить и применить 68 функцию получилось значительно позже. С ней гораздо легче реализовать такие вещи, но KFM в планах переписывания. А когда и библиотеку файловую сделаю, можно будет и KFAR прикрутить к ней.