On 15/10/16 10:57, Mike wrote:
Regarding these 4 issues, In My Humble Opinion:
#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.
Personally, I don't care about the disk order, different users might see
the in different sorting orders.
But I find it usefull to have some idea about what has allready been
done when arriving a a certain directory.
#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.
Sorry, but we must be referring to different situations.
As mc is now, when it encounters an allready existing destination file
(and the chosen option is in ex: skip when same size), it will skip the
file when it reaches it, without the need for a pre-existing file list.
The only need I see is to update the total files/volume counters. No
additional directory access required.
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.
I agree, but there are no heavy resources required.
Both of these can slow the copy/move operation considerably. Fastest
method consistently is disk-order/no-scan-files.
???
#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?
I get a single bar progress, until the two bar copy progress
My mc is 4.8.1 on Mint 13. I do regular updates, but never got the
recent releases.
And frankly, I'm getting old and don't know if I'd be OK compiling it.
:-)
--
Werner
mailto:skunkwo...@rikishi42.net
I don't suffer from insanity. I enjoy every moment of it.
_______________________________________________
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc
