OS/2, eCS & ArcaOS - Technical > Applications
LarsenCommander - new test version
Dariusz Piatkowski:
Hello Andi!
As the others have stated: big Thank You!!!
--- Quote from: Andi B. on May 19, 2023, 12:07:08 pm ---...Main difference to older releases is - I reenabled big buffers for file copy operations...
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....
--- End quote ---
So I'm curious about this: does the current Max Buffer setting still function, or is that now ignored by your enhanced logic?
I had previously set this to 10K, now set to 64K, tested across the local as well as LAN devices (Win boxes as well as a NAS), all still good.
OK, so I do have a 'feature request': WHEN looking at the contents of a ZIP file do you think you might be able to enable object recognition and the use of system-wide settings instead of the default editor that's defined in LCMD settings?
I'm literally thinking:
1) TEXT is fine
2) JPG, GIF, etc...do not work
3) MP4, AVI...do not work
...so am I perhaps missing something here, or is LCMD really limitted to just being able to treat everything inside a ZIP file as a TEXT file?
Thanks!
EDIT
====
I clarified that we are talking about ZIP file contents here...my original post did NOT spell this out at all!
Andi B.:
--- Quote from: Andy Willis on May 20, 2023, 07:28:48 pm ---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.
--- End quote ---
Yes I was confused by this more than once too. There's included the lcmd_text.cmd (and te.cmd) which calls
--- Code: ---start lcmd.exe -rcFile ..\..\lcmd.rc -rcSearchPath ..\..\src\glib;..\.. -iniFile lcmd.ini -logFilter test -logFile lcmd.log %1 %2 %3 ...
--- End code ---
--- Quote ---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.
--- End quote ---
I've ';.;' in libpath after the %unixroot% directories.
--- Code: ---LIBPATH=p:\usr\local\lib;p:\usr\lib;p:\dll;.;P:\.....
--- End code ---
So that's no problem for me. Isn't that the usual setup? I mean having ;.; in the libpath (best at the end or after unixroot dirs. Isn't it the standard behavior for OS/2 programs to search their dlls in libpath? Or start it by an object set to run in the programs directory?
Are you asking for some 'special' code in LCMD which loads the dll from the programs directory regardless of libpath setting? Are there some example programs for such?
Andi B.:
--- Quote from: Dariusz Piatkowski on May 26, 2023, 06:05:56 pm ---....
So I'm curious about this: does the current Max Buffer setting still function, or is that now ignored by your enhanced logic?
--- End quote ---
Currently it's only honored when you set it bigger than 16MByte. And only for the first file block which is copied. If the file is bigger than 16MB (or your setting) then the buffer may be increased when copying one block takes less than 40ms. And the buffer size gets decreased when copying a block takes more than 350ms. Actually the 'ideal' copy buffer size calculation is a bit more complex but the idea is to change the buffer size dynamically so that copying one block takes between about 40 - 350ms. This all has a big impact on real big files (lot of 100MBytes) and fast devices (f.i. SSDs or fast HDDs).
Originally the 'ideal' buffer size was calculated for a block transfer time of 4s (if I understand the code correct) but limited to your setting in the options and a rather small initial setting. I had to change that cause some overflow in the calculation leads to wrong buffer size and very slow transfer rates in some cases. Moreover I think most users didn't even find the setting in the options (like myself) and so the got only low transfer rates even with very fast devices.
With my current algorithm I have about 85MBytes/s when writing to HDDs and >140MBytes/s on some SSD. This is close enough to the limit my system is able to handle and I think most I can get out of a PM copy program with progress indication.
I mainly tried to optimize copy speed with big files and reals disks within the system. I've not seen a negative impact in copy speed for small files. Limited testing was done on different LAN or USB devices and different file systems (JFS, HPFS, FAT, FAT32) too without negative side effect. Unfortunately I've currently no chance to test fast USB3 devices. They do not work well on my system in general. So test result with different settings are welcome. Mind you always can compare speed with copy done from cli. Usually copy from cli is still faster. But not that much anymore than before.
--- Quote ---...
OK, so I do have a 'feature request': WHEN looking at the contents of a ZIP file do you think you might be able to enable object recognition and the use of system-wide settings instead of the default editor that's defined in LCMD settings?
...
--- End quote ---
I consider the vfs implementation (zip file handling) in LCMD as a proof of concept. Only basic functionality is implemented AFAIK. As you already have observed functionality is very limited. I never used this feature by myself. I find even file managers which implement such feature much better (TotalCommander on Win) as rather useless and I don't use it. Cause even there it never works nearly as good as a real Archive program manager (WinRar, 7-zip, Win folder zip integration, ...). I don't see any real chance for me to implement zip/rar/arj/tar/iso/... file handling in LCMD to an extend I by myself would call it nearly useful. Not even if I got fired by my company and could work full time on this ;-). So until no one else could invest a lot of time in this part of LCMD I would suggest setting 'System launch Zip's by default'.
Andy Willis:
--- Quote from: Andi B. on June 08, 2023, 11:19:04 am ---
--- Quote from: Andy Willis on May 20, 2023, 07:28:48 pm ---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.
--- End quote ---
Yes I was confused by this more than once too. There's included the lcmd_text.cmd (and te.cmd) which calls
--- Code: ---start lcmd.exe -rcFile ..\..\lcmd.rc -rcSearchPath ..\..\src\glib;..\.. -iniFile lcmd.ini -logFilter test -logFile lcmd.log %1 %2 %3 ...
--- End code ---
--- Quote ---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.
--- End quote ---
I've ';.;' in libpath after the %unixroot% directories.
--- Code: ---LIBPATH=p:\usr\local\lib;p:\usr\lib;p:\dll;.;P:\.....
--- End code ---
So that's no problem for me. Isn't that the usual setup? I mean having ;.; in the libpath (best at the end or after unixroot dirs. Isn't it the standard behavior for OS/2 programs to search their dlls in libpath? Or start it by an object set to run in the programs directory?
Are you asking for some 'special' code in LCMD which loads the dll from the programs directory regardless of libpath setting? Are there some example programs for such?
--- End quote ---
I have lcmd in path but am trying to avoid having to put the dll in the libpath. There is a way when calling the DLL to search the path the the executable is in first, ;.; only helps if you are in the directory that the DLL is in when you launch the executable. I should be able to find the code in Mozilla.
Andi B.:
I have lcmd in path but am trying to avoid having to put the dll in the libpath. There is a way when calling the DLL to search the path the the executable is in first, ;.; only helps if you are in the directory that the DLL is in when you launch the executable. I should be able to find the code in Mozilla.
[/quote]
Ok now I understand. Different people, different habits. I don't have the LCMD directory in PATH nor in LIBPATH. I've three different objects in xcenter which starts LCMD with different settings and at least one object on the desktop. Looking at it I now see one of them points to te.cmd. Others have '*' as 'Path and file name' and something like '/c set beginlibpath="P:\Util\Larsen Commander_OwnTest" && "P:\Util\Larsen Commander_OwnTest\lcmd.exe" -rcSearchPath P:\Util\Larsen Commander_OwnTest -rightDir E:\_work -leftDir E:\Dokumente -iniFile E:\home\lcm_own.ini' as Parameters. Now I see why I don't need it to bee in any (LIB)PATH :-)
If I have a need to start a program from cli then I usually have a *.cmd file in my default \batch file directory (which is in PATH). With this habit (objects in xcenters and .cmd files) for a lot of programs I keep my PATH and LIBPATH short. As said different users different needs.
Anyway if you find some solution for your problem maybe we can implement it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version