|
Thank you for the feedback. I am familiar with being annoyed when
your distro of choice has a crap version of something and doesn't
seem to care. Use the source, Luke. I wonder what Peter Norton's file manager of choice these days
is. I've never met Peter Norton. I think I installed some Norton
software in the 90s. I don't recall much about it or him so I have
nothing to compare. I think there is a nc clone/wannabee out there
somewhere, but mc is only similar by accident - the 2 panel thing.
Apparently it is a "visual shell for *nix environments", not a
"file manager", although I categorize it as one, like most users I
think. midnight commander has its origins from the 90s too. It
sucked far worse back then. The one thing I like above all with this project over similar
ones, is the pure hackablility of mc. It's pretty easy to
familiarize yourself with the code and make it do whatever you
think it should within a fairly short period of time. There are
numerous examples of some pretty impressive "hacks". mc2 and
mc-tabs come to mind immediately. >> #1: - copies are made in the disk order, instead of
taking the sort order that is chosen for the display I have wondered why this is the case myself. I can see the odd situation I would want to preserve disk order, but certainly not the majority of cases. At minimum it should be option. I have some recollection of a discussion about this issue on this very list back some years. It involves creating a temporary file list (and stat()ing a massive directory tree possibly) and parsing it according to arbitrary criteria. In this case, panel sort order. The list parsing can have some advanced options. Or each directory can be parsed as it is encountered (spread the delays out over entire operation). Alphabetical sort can be done with dirent, but any other criteria involves stat() or even more slow disk access stuff. Note here that the order in which files are copied still does not
mean much about the disk order they end up in on the destination
drive. Maybe some filesystems it does, but not mine. I can copy
files one by one and they still end up in whatever order the
underlying hardware wants them in. >> #2: - when some of the files are allready on
destination, and one choses to skip, their number and volume
should be substracted from the total count/size. In that way the
estimates mean something. This means you encountered one of many error conditions. And
handling this involves re-parsing the remaining file list
according to numerous arbitrary criteria, and can be very time
consuming. Just creating the file list can be very time consuming.
The test results in some cases are from trying to write the file.
This is not practical on large listings and many network
connections. Running estimates on lengthy file operations are
nearly impossible in many situations, especially when speed is
important, and can easily exceed the actual copy itself. Maybe option reparse_eta_on_error[=No]? Either that or have some
grotty list of arbitrary file parse criteria where we do various
things depending on error condition, file sizes, number, type of
connection, etc. in order to maintain the running tally. And if
we're going to go there, then create a big dialog or scripting
capability where you can specify stuff like "if (!file.error ||
file.dest.exists && file.dest.size > 3k &&
last.file.name == "foobar" && file.src.mtime.secs -gt
`date +%s 2>/dev/null` ) then cp -vf %f >> file.log
endif". Personally, I use it as a gauge of bytes transferred and not much
more. The ETA is exactly that: some estmation, and your mileage may
vary, as they say. Basically it means: Should I sit here, or can I
make tea? This should be in FAQ. Both of these can slow the copy/move operation considerably. Fastest method consistently is disk-order/no-scan-files. Both could be enabled by UNchecking fast_copy_mode and enabling a bunch of arbitrary widgets and sort methods. Perhaps this is the answer, at least enable panel-sort-mode because it's such a common request. Option #1 and #2 work well together on fairly small numbers of
files, but you certainly want them turned off for the transfer of
large numbers of files. This could be option also,
enable-fast-copy-when-file-qty-exceeds... n ? >> #3: - the move function still copies all, before
removing the files, meaning that we gain nothing in volume until
all has been copied Again, this can really slow things down. Imagine 250,000 small
files. Without option, you get copy of all data, then single long
delete process to finish. With option, last data transfer is not
made until the 2nd to last operation. Removal is less important
than getting the data to destination.This could be move dialog
option remove-source-on-fly, default = OFF. Good for large
files/small numbers. >> #4. - the move function doesn't give an estimate during
it's work My move works fine. Must be your version. What is it and how did it find it's way into your distro?
On 2016-10-14 14:27, Rikishi 42 wrote:
On 14/10/16 15:35, chris glur wrote: --
Peace and Cheer |