Re: mc Digest, Vol 146, Issue 10

[Yury V. Zaytsev]

On Fri, 4 Nov 2016, Guus Bonnema wrote:




On 3-11-2016 22:09, Yury V. Zaytsev wrote:

 On Thu, 3 Nov 2016, solarflow99 wrote:

>  Could this explain it?
> 
>https://mail.gnome.org/archives/mc/2016-October/msg9.html


 Most likely it can be simply explained by the fact that shell wrappers
 don't take effect until you re-login, so on a freshly installed system mc
 will not remember last directory right after installing the package.


I have been unclear. What I meant is that following a fresh install, MC 
doesn't remember the current directory after closing MC. So open MC, 
navigate, then close MC and you end up in the directory you started out in.


I understood what you meant; mc doesn't remember anything at all, this is 
done by shell wrappers, and these wrappers have to be activated first...


--
Sincerely yours,
Yury V. Zaytsev
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: mc Digest, Vol 146, Issue 10

[Guus Bonnema]

On 3-11-2016 22:09, Yury V. Zaytsev wrote:

On Thu, 3 Nov 2016, solarflow99 wrote:


Could this explain it?

  https://mail.gnome.org/archives/mc/2016-October/msg9.html


Most likely it can be simply explained by the fact that shell wrappers 
don't take effect until you re-login, so on a freshly installed system 
mc will not remember last directory right after installing the package.


I have been unclear. What I meant is that following a fresh install, MC 
doesn't remember the current directory after closing MC. So open MC, 
navigate, then close MC and you end up in the directory you started out in.


However, I haven't seen the problem in a while, so Fedora might have 
picked up on how keep the current directory when leaving MC.


Kind regards, Guus.

---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus

___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: mc Digest, Vol 146, Issue 10

[Yury V. Zaytsev]

On Thu, 3 Nov 2016, solarflow99 wrote:


Could this explain it?

  https://mail.gnome.org/archives/mc/2016-October/msg9.html


Most likely it can be simply explained by the fact that shell wrappers 
don't take effect until you re-login, so on a freshly installed system mc 
will not remember last directory right after installing the package.


--
Sincerely yours,
Yury V. Zaytsev


On Sat, Oct 15, 2016 at 3:07 AM, A.J. Bonnema  wrote:
  On 10/15/2016 10:57 AM, Mike wrote:
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.

  Hey Mike,

  I used to love Norton Commander (nc) because of its function keys for 
copy and move in combination with easy
  selection of files. Those are the traits that mc copied from norton and 
made me start using MC. Probably MC also
  copied the editting. In comparison to DOS at the time, Norton Commander 
was really a breeze of fresh air. He really
  thought things through. When I switched to Linux I went  to MC and never 
looked back. He also made other more
  system oriented software for windows, but I am getting OT now.

  Anyway, I like MC for the same reasons and especially for the reason it 
is reliable. With one exception everything
  works as I expect it to. The exception is that sometimes the current 
directory is remembered when finishing MC, and
  sometimes it isn't and you end up in the original directory that you 
started MC. This usually happens after full
  upgrade or installing a new OS (Fedora -> Ubuntu or back)

  I haven't seen this for a while, so probably the setup of MC has 
improved. I work from Fedora 24 atm.

  Kind regards, Guus.


  ___
  mc mailing list
  https://mail.gnome.org/mailman/listinfo/mc
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: mc Digest, Vol 146, Issue 10

[solarflow99]

Could this explain it?

  https://mail.gnome.org/archives/mc/2016-October/msg9.html




On Sat, Oct 15, 2016 at 3:07 AM, A.J. Bonnema  wrote:

> On 10/15/2016 10:57 AM, Mike wrote:
>
>> 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.
>>
> Hey Mike,
>
> I used to love Norton Commander (nc) because of its function keys for copy
> and move in combination with easy selection of files. Those are the traits
> that mc copied from norton and made me start using MC. Probably MC also
> copied the editting. In comparison to DOS at the time, Norton Commander was
> really a breeze of fresh air. He really thought things through. When I
> switched to Linux I went  to MC and never looked back. He also made other
> more system oriented software for windows, but I am getting OT now.
>
> Anyway, I like MC for the same reasons and especially for the reason it is
> reliable. With one exception everything works as I expect it to. The
> exception is that sometimes the current directory is remembered when
> finishing MC, and sometimes it isn't and you end up in the original
> directory that you started MC. This usually happens after full upgrade or
> installing a new OS (Fedora -> Ubuntu or back)
>
> I haven't seen this for a while, so probably the setup of MC has improved.
> I work from Fedora 24 atm.
>
> Kind regards, Guus.
>
>
> ___
> mc mailing list
> https://mail.gnome.org/mailman/listinfo/mc
>
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: mc Digest, Vol 146, Issue 10

[A.J. Bonnema]

On 10/15/2016 10:57 AM, Mike wrote:
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. 

Hey Mike,

I used to love Norton Commander (nc) because of its function keys for 
copy and move in combination with easy selection of files. Those are the 
traits that mc copied from norton and made me start using MC. Probably 
MC also copied the editting. In comparison to DOS at the time, Norton 
Commander was really a breeze of fresh air. He really thought things 
through. When I switched to Linux I went  to MC and never looked back. 
He also made other more system oriented software for windows, but I am 
getting OT now.


Anyway, I like MC for the same reasons and especially for the reason it 
is reliable. With one exception everything works as I expect it to. The 
exception is that sometimes the current directory is remembered when 
finishing MC, and sometimes it isn't and you end up in the original 
directory that you started MC. This usually happens after full upgrade 
or installing a new OS (Fedora -> Ubuntu or back)


I haven't seen this for a while, so probably the setup of MC has 
improved. I work from Fedora 24 atm.


Kind regards, Guus.


___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc

Re: mc Digest, Vol 146, Issue 10

[Rikishi 42]

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

[Mike]

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

[Yury V. Zaytsev]

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

Re: mc Digest, Vol 146, Issue 10

[Rikishi 42]

On 14/10/16 15:35, chris glur wrote:

..the presence of very basic defects in the file
management functions.


Please describe some of these.


- copies are made in the disk order, instead of taking the sort order 
that is chosen for the display
- 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.
- 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


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?




--
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

[chris glur]

>..the presence of very basic defects in the file
> management functions.

Please describe some of these.

==Chris Glur.


On 10/12/16, mc-requ...@gnome.org <mc-requ...@gnome.org> wrote:
> Send mc mailing list submissions to
>   mc@gnome.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://mail.gnome.org/mailman/listinfo/mc
> or, via email, send a message with subject or body 'help' to
>   mc-requ...@gnome.org
>
> You can reach the person managing the list at
>   mc-ow...@gnome.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mc digest..."
>
>
> Today's Topics:
>
>1. Re: mc Digest, Vol 146, Issue 7 (Rikishi 42)
>2. Re: mc Digest, Vol 146, Issue 7 (solarflow99)
>
>
> --
>
> Message: 1
> Date: Tue, 11 Oct 2016 17:51:42 +0200
> From: Rikishi 42 <skunkwo...@rikishi42.net>
> To: mc@gnome.org
> Subject: Re: mc Digest, Vol 146, Issue 7
> Message-ID: <3e4d6eba-1e5c-be02-36ed-a1e9aef85...@rikishi42.net>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 11/10/16 12:41, chris glur wrote:
>> how can you LIVE with one instance of mc ?!
>
>
> By using it for which NC (it's ancestor) was made:
> a file/dir manager, not a terminal.
>
> I'm amazed at the resources and time that go into the terminal
> maintenance and development, and the presence of very basic defects in
> the file management functions. Not to mention that those effords and
> updates don't seem to make it to some rather popular Linux distros.
>
> Peter Norton would not be happy.
>
>
> --
> Werner
> mailto:skunkwo...@rikishi42.net
> I don't suffer from insanity. I enjoy every moment of it.
>
>
> --
>
> Message: 2
> Date: Tue, 11 Oct 2016 09:48:16 -0700
> From: solarflow99 <solarflo...@gmail.com>
> To: Rikishi 42 <skunkwo...@rikishi42.net>
> Cc: mc@gnome.org
> Subject: Re: mc Digest, Vol 146, Issue 7
> Message-ID:
>   <cao8i5oj8rr9xplmqrpp12gp3ucled1jiwqqo_+12j6l2ymo...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> ha.
>
> On Tue, Oct 11, 2016 at 8:51 AM, Rikishi 42 <skunkwo...@rikishi42.net>
> wrote:
>
>> On 11/10/16 12:41, chris glur wrote:
>>
>>> how can you LIVE with one instance of mc ?!
>>>
>>
>>
>> By using it for which NC (it's ancestor) was made:
>> a file/dir manager, not a terminal.
>>
>> I'm amazed at the resources and time that go into the terminal
>> maintenance
>> and development, and the presence of very basic defects in the file
>> management functions. Not to mention that those effords and updates don't
>> seem to make it to some rather popular Linux distros.
>>
>> Peter Norton would not be happy.
>>
>>
>> --
>> 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
>>
> -- next part --
> An HTML attachment was scrubbed...
> URL:
> <https://mail.gnome.org/archives/mc/attachments/20161011/cd123c7c/attachment.html>
>
> --
>
> Subject: Digest Footer
>
> ___
> mc mailing list
> https://mail.gnome.org/mailman/listinfo/mc
>
>
> --
>
> End of mc Digest, Vol 146, Issue 10
> ***
>
___
mc mailing list
https://mail.gnome.org/mailman/listinfo/mc