OS/2, eCS & ArcaOS - Technical > Applications

LarsenCommander - new test version

(1/8) > >>

Andi B.:
Since a while I'm working on some problems in LarsenCommander again. There is still one problem I want to resolve before I make an official release. But as I'm preparing for holiday vacation I think it may be good to spread the current version to the public.

Main difference to older releases is - I reenabled big buffers for file copy operations. The advantage is much faster copy speed especially with big files. Copy speed is still not as fast as the copy command from a 4os2 command prompt but the difference is not as dramatic than before. I had to rework and extend the original dynamic buffer adaption code for this. It seems current copy speed is the maximum you can get when copying with an PM application.

The max. copy buffer size in old releases was determined by a simple algorithm and based on the setting in Options - Various - File Copy/move tab. I had to limit the buffer in some 1.7. release to 60k cause there was a subtle bug in ndfs DAV plugin which leads to some zero bytes in large files copied with the help of big buffers. The side effect was a limited copy speed at about 30MBytes/s I just discovered a few months ago. There's an old ticket about the ndpdav bug which is resolved in newer releases I think. So I think it's save to reenable big buffers again. For convenience I include my fixed ndpdav.dll in this lcmd*zip. But you probably don't need it. Current ndfs 3.1.6 also has changed in a way that such subtle plugin bugs shouldn't show up anymore. But be warned if you use old ndfs/ndpdav versions.

Lcmd also uses high memory for the copy buffer now. So if you watch your memory consumption (f.i. with above512.cmd or theseus) you may find a bit less memory usage from the scarce lower shared mem. Unfortunately this does not fix another long standing problem - copying big trees of directories sometimes leads to eat up a lot (sometimes all) lower shared memory. This may eventually bring your system down until you kill lcmd. Finally I can reproduce this problem but unfortunately I don't have a fix for this right now. If you ever run into this bug in the past, sorry there's no fix in this release for that.

In this archive I've also included the current available translations. When you want to use lcmd with another language or make your own translation look into the locale directory.

I've also checked in all current sources at the official home of LarsenCommander - https://sourceforge.net/projects/lcmd/

Have fun :-)

Martin Iturbide:
Hi Andi B.

Thanks for taking the time to update Larsen Commander.

I was trying the new version and I have a little question or issue. When I have a file on the right side, and I want to copy it to the left side (Different folder). I select the file and click "copy", a popup shows telling me that it will copy the file from here to there, I click ok, the file get copied but the desktop windows loose focus, the focus moves around and a window from the background gets to the top. (Maybe the pictures explain my problem if my wording is not clear enough)

It also happens when I delete a file with the right click menu too.  Is that only happening to me? 


Andi B.:
Maybe you're bitten by the same bug I mentioned in the ToDo.txt file more than 12 years ago ;-) (20100810 After deleting files focus changes to another not lcmd window).

I remember I added some debug messages back then when I tried to track this down. But couldn't solve this. But as this is a nuisance for me too chances are high that I finally will fix it.


Andy Willis:
Thank you Andi.
I updated my local svn and built it.  Thought I had a problem with the executable at first, I tried to test the built lcmd.exe in the directory it was built in and it threw errors but I figured out it was reading the lcmd.rc for building it and the executable needs its own lcmd.rc file.  Once I worked that out, it seems to be working well.
One thing that I would like I would like to see (maybe I can work it out) is to have lcmd.exe look for gl16os2.dll in its own directory first before looking at libpath, this would allow it to run without gl16os2.dll having to be in libpath.

Andi B.:

--- Quote ---this would allow it to run without gl16os2.dll having to be in libpath.
--- End quote ---
I don't think I've it in the libpath. But I will check next week.


[0] Message Index

[#] Next page

Go to full version