far2l
far2l copied to clipboard
elfmz
sftp improvement proposal (remote find file etc)
Another crazy feature request.
Two operations are currently too slow via SFTP: folder size calculation and files search. The problem is that all recursive operations are done on the client side, so many network data transfer operations are required.
What if we implement some custom sftp extensions (with serverside far2l acting as custom sftp subsystem) allowing those to be done on server?
Same thing with sudo password requests or privileges elevation requests.
This model would also be useful for adding comfortable tree panel, info panel, find folder, wipe file and archive management functionality to NetRocks/sftp.
Another way of implementation is running corresponding shell commands (du -s, find/grep -rnw '/path/' -e 'pattern', etc) on server and parsing their output. Not sure which way is better, but this is much simplier I guess and do not require far2l to be installed on server. But this will require reimplementing some of core far2l functionality using "shell backend".
It may be somekind difficult to implement search in archives and support for different encodings, but limitation of this functionality is an acceptable price for increase in speed. Clientside search can also be left as alternative option.
if there is far2l installed on other side then its possible to just run it and have that all right now without extra SSH hacking.
The dream is to have one panel local, another - remote, both working at the speed of light.
With remote far2l in terminal I do have speed of light, but both panels show remote host. With NetRocks I have one panel local, one remote, but some operations are too slow on remote panel.
The idea is to combine advantages of both methods.
Btw, shell way seems to be preferred as I simply can not install far2l on all hosts I am working with :)
UPD: "Find file" currently looks to be broken at all in netrocks, see #559
What if we implement some custom sftp extensions (with serverside far2l acting as custom sftp subsystem) allowing those to be done on server?
Btw, it's may be tricky with sftp/scp, but may be relatively easy with fish.
А ведь правда, с помощью протокола shell/fish мы фактически пробрасываем API работы с файловой системой через SSH. Почему бы при этом не вынести на сторону сервера все рекурсивные операции, типа поиска файлов и строительства дерева файловой системы? Радикально быстрее станет же.
Для тех случаев, когда железка настолько простенькая, что far2l в неё не запихаешь, при этом какой-никакой ssh туда — есть, а удобства — хочется.
И туда же — операции copy и move делать прямо на стороне сервера, если на обоих панелях один и тот же сервер открыт. Про это у нас отдельный тикет был даже, #1436
И теоретически этим же способом можно было бы сделать так, чтобы viewer не грузил весь файл с сервера сразу, а читал только диапазон байт, который показывается на экране в данный момент.
И туда же — операции copy и move делать прямо на стороне сервера, если на обоих панелях один и тот же сервер открыт.
move сейчас именно так и работает. copy - нет, не так. Просто потому что ни один протокол нативно не умеет в on-site copy (исполнение шелловских команд не есть нативно). SHELL в принципе можно сказать что нативно умеет в такое, да и про scp можно так сказать (поскольку нативно он почти ниче не умеет), но это прям так реально нужно?
теоретически этим же способом можно было бы сделать так, чтобы viewer не грузил весь файл с сервера сразу, а читал только диапазон байт, который показывается на экране в данный момент.
Теоретически можно, по факту это расширение плагинового апи, ща там есть GetFilesW который файлы целиком выкачивает, а нужно значит добавить GetPartOfFile, и реализовать это расширение в плагине и заюзать его во вьювере (что будет самым сложным)... И все это ради одного лишь viewer'а, причем стандартного, так как все тулзы во view.sh этим пользоваться конечно же не будут.. Стоит оно того?
Если менять плагиновый апи, то тогда и поиск файлов и построение дерева (и что там ещё есть рекурсивного, если есть) добавить бы сразу, чтоб потом не менять api ещё раз. По viewer'у — ну, выкачивать длиннющие логи такое себе :)
Ну а find это еще одна отдельное расширение, перпендикулярное расширению вьювера. Хотя надо признать - оно видится более полезным и проще в реализации чем плюшки для вьювера
Так это как раз для совсем простого embedd'а, где «там» не запустить. Поиск нужнее, согласен!
но это прям так реально нужно?
в чате пишут что нужно, ага
Коммент был от меня. Если будет возможность на удаленной стороне пользоваться удаленными же тулами -- будет круто. Сейчас при большом расстоянии до сервера всё очень неспешно, даже при удалении. Копирование с удаленной фс на удаленную я даже не пытаюсь практиковать.
