Re: mc Digest, Vol 146, Issue 10
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
Re: mc Digest, Vol 146, Issue 10
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. 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. >> #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
Re: mc Digest, Vol 146, Issue 10
On Fri, 14 Oct 2016, Rikishi 42 wrote: - copies are made in the disk order, instead of taking the sort order that is chosen for the display This could be an interesting feature to implement: if I remember correctly, Volkov Commander did that, and on top, it removed the selection dynamically from the files already copied, so you could literally see how your files float from one directory to another. - 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. I'm not sure why do you think it would mean something, I believe exactly the opposite. - the move function still copies all, before removing the files, meaning that we gain nothing in volume until all has been copied - the move function doesn't give an estimate during it's work This is a safety feature introduced by design to make sure that moves are atomic in a sense that nothing is removed before the copy part succeeded. I think some of these bugs might have been removed from the latest mc, but I can't find a recent update for Linux Mint. How do you expect feedback from people, if most of them can't get recent releases? There are unofficial Mint-compatible binaries provided on the Binaries page, you just have to figure which Ubuntu / Debian stream corresponds to your Mint release. -- Sincerely yours, Yury V. Zaytsev ___ mc mailing list https://mail.gnome.org/mailman/listinfo/mc
