Относительные пути отсчитываются от текущей папки, а вовсе не от рамдиска. Так что это будет работать, только пока никакая программа (в цепочке "предков" kfar) не использует функцию 30. Не пойдёт.

Mario79 wrote:Похоже, в новой доработке FAT содержится какой-то недочет. Вчера копировал папку с исходниками ядра при помощи KFAR (KFM пока не поддерживает копирования вложенных папок и файлов), работал с файлами. А сегодня загружал Винду - долго ругалась и что-то исправляла в той папке. Папка в результате нормальная, но имена стали, написаны большими буквами и обнаружились потерянные сектора в папке созданном виндовым скандиском.

Упс... Всем скачавшим ядро начиная с svn.649 срочно качать svn.654.

P.S. Пытаться скомпенсировать исправлениями ядра неправильный выбор алгоритма приложения не лучший выход из положения. Я уже писал, что вся проблема в том, что ты выбрал фиксированный размер блока для копирования и за счет огромного количества дополнительных операций скорость падает значительно. Гораздо эффективней перекинуть за один заход большой кусок файла, как я сделал в KFM. Я не призываю брать мой код за основу, но может стоит задуматься?

Доработка ускоряет запись во всех случаях.
Допустим, идёт копирование большого числа маленьких файлов. Тогда kfar и kfm работают одинаково тормознуто. Доработка ускоряет в том числе и эту ситуацию. Допустим, идёт копирование очень большого файла, не влезающего в физическую память. Тогда kfm, конечно, быстрее kfar, но всё равно он ускоряется.

diamond wrote:Относительные пути отсчитываются от текущей папки, а вовсе не от рамдиска. Так что это будет работать, только пока никакая программа (в цепочке "предков" kfar) не использует функцию 30. Не пойдёт.

Действительно, VIEW3DS перестал запускаться по ассоциации...
А что, если в ini-файле вместо /rd/1/ писать /sys/? Это ведь допустимо, и тратится на один символ меньше, так что небольшая экономия будет

kfar
-------
очень не хватает F7 в режиме просмотра.

newbie
Принято к сведению. Но не рассчитывай на быструю реакцию.

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

Небольшой баг в новой и предыдущей версии kfara. На определённом файле просмотр по F3 с его конца(если после ENDа преремещатся по нему с помощью стрелки вверх в течении секунд 5) происходит неправильное отображение содержимого. Глюк замечен и в klbrinwin.
http://ifolder.ru/5378923

Действительно, есть.
Кроме того, если потом с помощью стрелки вернуться немного вниз, а потом опять вверх, глюк повторяется.

C ревизии 758 появился небольшой баг(см. скриншот), когда в первые за весь сеанс работы системы кфар обращается к cdromу появляется эта бага. 757 его нету. А если обращаться через Eolite, то он падает. В KFM всё нормально.

Скомпилировал из исходников новую версию kfar и kfar_arc.obj
При запуске пишет, что не может загрузить kfar_arc.obj, потому что несовместимая версия.
Что делать? Может библиотеки обновить? А где взять новые?

Maxis wrote:Небольшой баг в новой и предыдущей версии kfara. На определённом файле просмотр по F3 с его конца(если после ENDа преремещатся по нему с помощью стрелки вверх в течении секунд 5) происходит неправильное отображение содержимого. Глюк замечен и в klbrinwin.

Это не баг, это особенности алгоритма определения начала и конца строк. А именно: после перехода в конец файла по End и дальнейшего прокручивания вверх просмотрщик должен переходить на предыдущую строку. Соответственно он сканирует файл назад в поисках символов перевода строки. Но сканирование ограничено некоторой величиной (8192 символа), чтобы он не уходил слишком далеко (заставлять его сканировать до упора может пагубно сказаться - мало ли где может быть этот перевод). Так что если строка длиннее 8192 символов, то до начала строки просмотрщик не дойдёт, и покажет только часть строки. При дальнейшем поднятии вверх будут появляться предыдущие части строки.
Зачем это сделано? Представим себе файл на 10 Гб, состоящий из печатных символов, за исключением одного места где-то в районе 3 Гб, где стоит перевод строки, и стандартный режим переноса длинных строк. Перейдём в конец файла. Если требовать точного отображения, то нужно найти этот символ переноса, сканируя назад, потом вернуться в конец, отсчитывая по 80 символов (в общем случае - по ширине окна просмотра). Что потребует перелопачивания 7 Гб и вряд ли приемлемо. В то же время ограничение в 8192 символа порождает неточное отображение, но ничего не теряет (в смысле, пользователь по-прежнему может увидеть все данные файла) и гарантирует от тормозов в подобных ситуациях.

Maxis wrote:C ревизии 758 появился небольшой баг(см. скриншот), когда в первые за весь сеанс работы системы кфар обращается к cdromу появляется эта бага. 757 его нету. А если обращаться через Eolite, то он падает. В KFM всё нормально.

Уже давно исправлено в ревизии 800 (это был баг ядра).

Атауальпа wrote:Скомпилировал из исходников новую версию kfar и kfar_arc.obj
При запуске пишет, что не может загрузить kfar_arc.obj, потому что несовместимая версия.
Что делать? Может библиотеки обновить? А где взять новые?

При использовании версии с svn не должно быть проблем с несовместимой версией. Единственный вариант - kfar пытается загрузить старый файл вместо свежескомпиленного, проверь настройки из kfar.ini.

Насчёт сообщения kfar о несовместимой версии kfar_arc.obj - это у меня были глюки с синхронизацией своих наработок с svn-версией. В svn.926 проблем быть не должно.

Сейчас смотрю документацию (api.txt) по плагиностроению, там говорится, что version должно быть равно 2, но в коде kfar_arc.asm фигурирует 3, это как?

..bw

Забыл обновить (точнее, залить на svn) документацию - для kfar 0.5 правильное значение version=3. Изменения коснулись структуры DLGDATA, которая всё равно в api.txt не описана, так что остальная часть api.txt по-прежнему верна.