Background Copy - Queue

[nand]

I often end up starting a local network copy, and then I realize how large the files are, and then it would take time.

Obviously, I click on Background, in order to move on with my work, and leave the copying process running.

BUT a nice option that exists in Queue Copy, doesn't exist in Background Copy. Speed limiting (a number of computers on the local network almost stop running, due to hard disk overuse!, and so I need to state a speed limit)

Would be nice to have it, and as a Delphi programmer, I know it's easy to fix. Right, Chris?

PS: I forgot to say GOOD WORK, CHRIS for this commander that actually cannot be beaten - I've tried different commanders, and, maybe it's me, but the ease of use it's marvelous

PS2: I made a bet once - who would do various tasks quicker?Me, using TC, or somebody using Windows Explorer.. In the end.. I think the quickness was around 10%... and imagine that I was not rushing at all, while the other guy was almost working with "3 hands" to keep up

[Hacker]

Abrakadabra, there's a new Wiki entry - Always copy / move in Queue.

HTH
Roman

[nand]

hmm. that would do it. but my question is? how, where do i implement it?

i'm quite an old user of TC (around 5 years), but i didn't bother going into it's depth, other than customizing it and adding various plugins. so, can you help me with this?

and actually, there's another thing. A QUEUE is still a QUEUE, while background copy is background copy. One copies files as a FIFO, the other is multithread copying.

[icfu]

Revisit the link from Hacker and click on the link at the bottom.
After installation of AutoHotkey edit the default AHK script or create a new .ahk-file, copy&paste the code and run it.

Icfu

[nand]

this is more like a hack. use an external application to add functions to TC, instead of adapting TC...

too much of a microsoft windows perspective... where almost any problem needs to be hacked, or just use a workaround...

[icfu]

If you don't like it, don't use it.
Some people prefer waiting till every single unimportant wish gets implemented directly in Total Commander, other people are realistic and use workarounds.

Icfu

[Sheepdog]

and actually, there's another thing. A QUEUE is still a QUEUE, while background copy is background copy. One copies files as a FIFO, the other is multithread copying.

But a speed limit for multithread copying makes no sense (IMHO):

You got bandwidth of say 100 Mbit/s. You limit the first background copy to 70%. You limit the second background to 70%.

You lack of 40 Mbit/s performance to fit only these two Tasks - but the goal to keep free some bandwidth for other operations you will miss.

That for you will need the QoS-Service upon the whole system.

sheepdog

[nand]

If you don't like it, don't use it.
Some people prefer waiting till every single unimportant wish gets implemented directly in Total Commander, other people are realistic and use workarounds.

I know, I know..
I perfectly agree with you on "don't like it, don't use it".
And I am realistic about all the major things, generally, yet I don't see it as an unimportant wish, and by far not an important wish. It is more of a structuring matter - if there's the option of speed limit in queue, why shouldn't it be in normal copy, and in background copy?!

[nand]

It seems, that I'm always replying after Sheepdog's replies tonight.

Speed limit for multithread copying it's what it is... HIGH LIMITING the SPEED.

You're not saying TRASNFER INFORMATION AT THIS SPEED, but TRANSFER INFORMATION BY NOT EXCEEDING THIS SPEED!

If you transfer something, just 1 thread, can also, just as well, occupy the whole bandwidth. When you start another copy thread,... the transfer speed will divide to 2.. So I really don't see why you're worrying about not being able to keep some bandwidth free.

That's not even the point, why I use speed limit. I often send large files with..let's say 9Mbps (inside the LAN) and some people just have their hard drives put to full use, and their system almost blocks. Instead I can limit my speed to, let's say 3Mbps.. I still send/receive a file, and that person can carry on because the hard drive has the power to do its user's job, while seamlessly copying the file too.

[Sheepdog]

If you transfer something, just 1 thread, can also, just as well, occupy the whole bandwidth. When you start another copy thread,... the transfer speed will divide to 2.. So I really don't see why you're worrying about not being able to keep some bandwidth free.

That for TC would have to keep track of all copy/move operations to check if there is a limit set and if yes, which limit and if there different limits set on the different copy/move operations decide which one is the valid one (the lowest, the last set).
I think this is a big task that should be done by a QoS Manager.

[/quote]That's not even the point, why I use speed limit....[/quote]

That you made clear in the first post. Neverthless you have to take account of the other aspects of the problem.

And one of those aspects is the above mentioned. And another thought: If I can limit the bandwidth for any copy/move operation, why not temporarily increase the bandwidth for one single one e.g. full bandwidth for unpacking an archive? A QoS Manager should be able to provide this but I think it's not the task of a filemanager.

sheepdog

[nand]

That for TC would have to keep track of all copy/move operations to check if there is a limit set and if yes, which limit and if there different limits set on the different copy/move operations decide which one is the valid one (the lowest, the last set).

Yes, keep track of each and every limit... yet... the valid one?! every windowed background copy has its own limit. Which is the valid one.

The last limit set/activated will become the default new (not activated) limit (as it happens with Queue).

If I can limit the bandwidth for any copy/move operation, why not temporarily increase the bandwidth for one single one e.g. full bandwidth for unpacking an archive? A QoS Manager should be able to provide this but I think it's not the task of a filemanager.

The "task" of a file manager is to manage file (copy/delete/rename/etc). Other than this, there are only IMPROVEMENTS to a file manager. Hence speed limiting. Having an Uninstaller plugin is also not the task of a file manager, yet there is one, considered as an plus, an extra to the basic purpose.

I really don't see this speed limiting from a network-related view, but more like hard-drive usage. Scenario: when I burn a DVD at high speeds, and also work (copy files) with TC, just to be Safe, I set a limit to the copying, so that there's no buffer underun while burning the DVD.

Also, just as a final argument - if speed limiting was not something that a file manager should deal with, why is there such an option in the Queue copying in the first place?

[Sheepdog]

I think speed limitation makes only sense if it is kept on the whole copy/move operations (of one Application). Thus I can set a limit at 5 KiB/s and know there left 2 KiB for other operation (if I have 7 KiB Bandwidth). And regardless how many operations I will start there will still be 2KiB bandwidth for other applications left.

But As you can perform 20 copy/move/pack/unpack operations within one instance of TC simultaneous ( or even more) it will cost a lot of performance of TC to keep track of all speed limitations of all those threads and to divide the bandwidth between all of them.

So I think it is not a good idea. That' all.

sheepdog

[icfu]

And I am realistic about all the major things, generally, yet I don't see it as an unimportant wish, and by far not an important wish.

My answer was meant general, regarding all tasks that can be solved by AutoHotkey and for which ghisler has no desires/time/understanding.

Of course I would like to have everything integrated in TC too, but as reality proves that this wish will never come true I have to find alternatives.

The good thing about the AHK hotkeys is that they don't use resources when idling due to the keyboard hook, so for me and many other addicts AHK is not a workaround anymore but an application that runs anyway.

Icfu