During testing of the latest beta series, it was noted that performance could be improved by moving the configuration and log files to isolated directories. This allows the file system change events to fire much more selectively. The new subfolders are "logs" and "config", for the logs and configuration file, respectively.
Full handling of this for existing installs isn't complete in this beta, though it will migrate your configuration file over if using the default folder and not using global path over-rides (mandated during core engine as service installs). Better migration and notification when the log and configuration folders are the same will be handled in an upcoming build before final.
So we can chose to delete the older ini/config file, not that they are big :)
Right click on logs will bring up "jump to log file on disk" where both original files are .
Or just wait, the cleanup function I haven't finished yet, it will fix the mess up. I'm leaving my test beds 'dirty' for testing of this mechanism. This change requires a lot of regression testing in all, but is well worth it.
The jump to log actually already works correctly, but in your case the new log folder may not be utilized yet - a global over-ride was probably stored and I haven't handled those yet.
right, I will leave mine dirty just to test it .
Was merely stating for those with OCD , that can't stand a extra file in there ;D
I just finished the necessary functions, so it will self-clean in v6.0.3.23 beta. There's much more code to work on related only to this change.
I'm biting off quite a bit in this beta series. In fact, the end result may warrant a more major version change.
The jump to log actually already works correctly, but in your case the new log folder may not be utilized yet - a global over-ride was probably stored and I haven't handled those yet. Many existing users will have these stored in the registry.
Sorry for misunderstanding, the jump to disk is working right (now pointing to new folder "log" ) .
I was just showing easy way to get to log and config folders (to delete manually if wanted to ) .
Check PM for another issue
Also, you can access various Process Lasso paths by modifying commands in that thread: https://bitsum.com/forum/index.php/topic,2709.0.html
To fire 2 Process Lasso INIs:
for %A in (HKEY_CURRENT_USER;HKEY_LOCAL_MACHINE) do (for /f "tokens=3*" %B in ('reg query "%A\Software\ProcessLasso" /v "ConfigFile"') do "%B %C")
To open Process Lasso log folder:
for %A in (HKEY_CURRENT_USER;HKEY_LOCAL_MACHINE) do (for /f "tokens=3*" %B in ('reg query "%A\Software\ProcessLasso" /v "LogFolder"') do if exist "%B %C" (explorer "%B %C")))
To open Process Lasso installation folder:
for /f "tokens=3*" %B in ('reg query "HKEY_CURRENT_USER\Software\ProcessLasso" /v "Install_Dir"') do if exist "%B %C" (explorer "%B %C")
Just copy-paste one of these one-liners into the Command Prompt window.
Good tips. ;)
QuoteDuring testing of the latest beta series, it was noted that performance could be substantially improved by moving the configuration and log files to isolated directories. This allows the file system change events to fire much more selectively. The new subfolders are "logs" and "config", for the logs and configuration file, respectively.
And why this can be happen? :)
Thanks hanebach_gt :).
The latest beta will correctly handle a global path over-ride on the log folder. The configuration file is actually less important (more important that the two are separated), but I'll be handling the path over-ride on it next.
Quote
And why this can be happen?
The Windows file-system change notification events have a folder granularity. These events are used to monitor a folder so that one knows instantaneously when file(s) in that folder have changed, without having to resort to polling. When both are in the same folder, writes to the log file trigger the change notification event for the folder, causing the configuration file to be checked an extraneous time for its own modification.
I probably over-stated things when I said substantially improved, but an improvement none-the-less ;o.
Quote from: Support on April 23, 2013, 06:53:42 PM
The Windows file-system change notification events have a folder granularity. These events are used to monitor a folder so that one knows instantaneously when file(s) in that folder have changed, without having to resort to polling. When both are in the same folder, writes to the log file trigger the change notification event for the folder, causing the configuration file to be checked an extraneous time for its own modification.
I probably over-stated things when I said substantially improved, but an improvement none-the-less ;o.
So, it helps on reduce the CPU usage, or reduce the Hard Disk usage? :)
Both, a little. The call out to check to see if the configuration file actually changed takes a small amount of blocking I/O.
Did this is a bug?
"C:\Program Files(x86)\Free Download Manager\fdm.exe ""C:\Program Files(x86)\Free Download Manager\fdm.exe"
"C:\Windows\system32\NOTEPAD.EXE""C:\Windows\system32\NOTEPAD.EXE"C:\Users\***\AppData\Roaming\ProcessLasso\logs\prolasso.log
For More info, it repeat showing 2 times, but the command line show correctly.
Yes, the log file does read from right place (new log folder) . the config ini is still using the original path , I did have a issue were I had to reenter my power profiles and also couldn't remove/edit from GUI power profiles .
But today it is working so not sure what happened yesterday .
one question , is it right that log file if opened with say notepad or wordpad the text is spread out a lot , maybe that is new format .
Quote from: BenYeeHua
Did this is a bug?
"C:\Program Files(x86)\Free Download Manager\fdm.exe ""C:\Program Files(x86)\Free Download Manager\fdm.exe"
"C:\Windows\system32\NOTEPAD.EXE""C:\Windows\system32\NOTEPAD.EXE"C:\Users\***\AppData\Roaming\ProcessLasso\logs\prolasso.log
For More info, it repeat showing 2 times, but the command line show correctly.
That is in the application command line? It is actually not a bug, though is a bit confusing. *Some* applications, depending on how they are executed, end up with their executable pathname as the first argument on the command line (arg[0]). So, Process Lasso is reading these command lines as they stand. Whether I should trim them to remove arg[0], when it exists, is something I will consider!
Quote from: edkiefer on April 24, 2013, 07:21:41 AM
Yes, the log file does read from right place (new log folder) . the config ini is still using the original path , I did have a issue were I had to reenter my power profiles and also couldn't remove/edit from GUI power profiles .
But today it is working so not sure what happened yesterday .
Hmm, I may see something during update testing. I have to make sure the upgrade path is seamless from the last final, and try to make sure it also works for the beta users ;p.
Quote from: edkiefer on April 24, 2013, 07:21:41 AM
one question , is it right that log file if opened with say notepad or wordpad the text is spread out a lot , maybe that is new format .
The log file is no longer in text format. While you can see some plaintext, at least for now, it is filled with NULLs (0 bytes) to pad out static length character arrays. Other binary data types are also contained within the file, and as these are populated, they would show as garbage in between the character arrays of plaintext. I may obfuscate it just to make it clear that it's not a text file, and definitely shouldn't be edited in a text editor.
Quote from: Support on April 24, 2013, 10:24:19 AM
That is in the application command line? It is actually not a bug, though is a bit confusing. *Some* applications, depending on how they are executed, end up with their executable pathname as the first argument on the command line (arg[0]). So, Process Lasso is reading these command lines as they stand. Whether I should trim them to remove arg[0], when it exists, is something I will consider!
Hmm, I may see something during update testing. I have to make sure the upgrade path is seamless from the last final, and try to make sure it also works for the beta users ;p.
The log file is no longer in text format. While you can see some plaintext, at least for now, it is filled with NULLs (0 bytes) to pad out static length character arrays. Other binary data types are also contained within the file, and as these are populated, they would show as garbage in between the character arrays of plaintext. I may obfuscate it just to make it clear that it's not a text file, and definitely shouldn't be edited in a text editor.
Yes , I figured it was new format, I was not trying to edit it, just read it to see information matched what was shown in log in GUI .
Also seems there is issue with power profiles but I posted issue in bugtrack .
Quote from: Support on April 24, 2013, 10:24:19 AM
That is in the application command line? It is actually not a bug, though is a bit confusing. *Some* applications, depending on how they are executed, end up with their executable pathname as the first argument on the command line (arg[0]). So, Process Lasso is reading these command lines as they stand. Whether I should trim them to remove arg[0], when it exists, is something I will consider!
Hmm, I may see something during update testing. I have to make sure the upgrade path is seamless from the last final, and try to make sure it also works for the beta users ;p.
I should make some highlight correction, for "More info", it show twice.
But for "Command line", it show correctly. :)
So the Capital don't works for this, learned. ;)
QuoteThe log file is no longer in text format. While you can see some plaintext, at least for now, it is filled with NULLs (0 bytes) to pad out static length character arrays. Other binary data types are also contained within the file, and as these are populated, they would show as garbage in between the character arrays of plaintext. I may obfuscate it just to make it clear that it's not a text file, and definitely shouldn't be edited in a text editor.
Yup, I just copy it and paste to Notepad++, replace all space with empty, then put back the correct space. ;D