Settnigs (highlights/tabs/filters) are overwritten when using multiple instances with portable configuration

[jrobi-atx]

Windows 10 Pro 21H2

Currently using LogExpert 1.8.7 on a Windows laptop (Windows 10 Pro 21H2) and a couple other Windows machines. And there seems to be a problem with the software overwriting the settings when using multiple instances of LogExpert in different folders....all using portable mode. But this seems to happen when the instances are using a common settings folder like AppData or MyDocuments.

Basically, all seems ok if there is one instance. I usually have anywhere from one to three files open in an instance...and a number of tabs created by the "filter to tab" functionality (which is awesome by the way). All files are using the default single line columinzer. And I have been able to replicate this on several machines.

I figured that it had something to do with me pointing to the same file from more than one instance. So I aliased the remote machine (via the hosts file) I was pointing to to create a "unique" file so that each instance was pointing to a single/unique file and there would be no chance of overwriting, but it happens anyway. And the past few weeks after I would reboot the settings were not just overwritten, they were gone. I have excluded all instances of LogExpert from my anti-virus but it keeps happening, and I am not sure what to do at this point. Have even tried to use sessions instead of depending on LogExpert's ability to reopen the same files...but no joy.

I am pointing to a number of continuously appending logfiles that start off from zero at the beginning of the week....since I archive/remove them at the end of the week. So this does not seem to be a performance issue. Checking over the past few weeks, the file sizes never get over 350Kb for the week.

There does not seem to be an error...just odd behaviour in the UI sometimes when I attempt to load a previous session when the settings have been gutted.

[jrobi-atx]

Thanks in advance and let me now if you need any more info...since there are no errors, I am at a loss as to what to upload to make it easier for you to track down the issue. Will try for a before and after when this happen again.

[Hirogen]

I might have an idea why this is happening normally if logexpert finds a "settings" file and just loads that, problem with that, after loading it, the file is instantly "saved" again.

Do you use different versions of logexpert, 1.8.8 RC and 1.8.7 are not compatible, due to the fact that the binary-formatter includes the assembly version in the saved files.

[jrobi-atx]

Hey...thanks for the response....

I only use one version of LogExpert...1.8.7. But if you think I should move to 1.8.8 in order to get beyond this, then I can do that....if there is anything I should be doing differently (except not trying to use more than one...since LogExpert is just that awesome) I will do that. I also use LogFusion (which is good), but LogExpert's ability to filter-to-new tab and move the windows around (so it acts like a saved query that I can reference quickly without all the other clutter lines getting in the way) is gold.

Hoping that I can import the settings from 1.8.7 into 1.8.8...but if I can't then that will be ok too. Just don't want to have to keep inputting the settings after a reboot...since that is sort of driving me nutz a little.

As far as "finding a settings" file, i tried putting the separate instances into their own folder and havinng them reference that folder for their *.lxj files and settings...but it seems like after the first instance is in memory, then the other ones look to that (first) one for something...not sure what...and that's when the trouble starts. Also....seems like when importing the Hightlights only (leaving the other persistance objects de-selected) the settings import also includes references to paths that the target-instance should not "know" about.

If you have any suggestions or need more info plz let me know...and also let me know if I can import from 1.8.7 to 1.8.8....and I can give it a try. Thanks!!

[Hirogen]

hmm strange behaviour, i have to test this. But you can try the Re-Release of the 1.8.7 version, to get all your settings as json file, this will help you import them in 1.8.8.

[jrobi-atx]

Will do...the fact that a lot of times, the files/filter tabs do reopen but after a reboot, it typically has issues has me scratching my head....when you look at the session file it does reference the persistence file. But it also has lines like the following:

...this makes me think that the issue/s may have something to do with temp files either being changed or possibly being gone. (I don't clean up my temp files after or before reboot.)....but reboots that occur when the LogExpert/s is/are still open may point to the issue. Thinking that if the temp files are gone or not saved correctly, then problems may be a bit more likely to happen. Not sure what all is saved in the temp files, but if maybe some of the more necessary bits are moved to your new json file info setup, that may be helpful.

But that is just me as a user just trying to throw spaghetti at the wall to try to explain the behaviour I have been noticing. I may be completely incorrect.

Anywhoo...again...plz let me know if there is anything you need. I will try the new Re-release of 1.8.7 over the weekend when i have more time to input the settings.

Thanks again Mr. Patrick.

[jrobi-atx]

Here is the example of the lines I was speaking of...was trying to copy/paste but for some reason, it did not make it in the last post...

[jrobi-atx]

Contents Count="6">
Content ID="0" PersistString="LogWindow#\ComputerName\PRINTED_AlertsFile\FileName.csv" AutoHidePortion="0.25" IsHidden="False" IsFloat="False" />
Content ID="1" PersistString="LogWindow#C:\Users<username>\AppData\Local\Temp\tmp21C0.tmp" AutoHidePortion="0.25" IsHidden="False" IsFloat="False" />
Content ID="2" PersistString="LogWindow#C:\Users<username>\AppData\Local\Temp\tmp229C.tmp" AutoHidePortion="0.25" IsHidden="False" IsFloat="False" />
Content ID="3" PersistString="LogWindow#C:\Users<username>\AppData\Local\Temp\tmp2349.tmp" AutoHidePortion="0.25" IsHidden="False" IsFloat="False" />
Content ID="4" PersistString="LogWindow#C:\Users<username>\AppData\Local\Temp\tmp23B7.tmp" AutoHidePortion="0.25" IsHidden="False" IsFloat="False" />
Content ID="5" PersistString="LogWindow#C:\Users<username>\AppData\Local\Temp\tmp8C90.tmp" AutoHidePortion="0.25" IsHidden="False" IsFloat="False" />
/Contents>

[jrobi-atx]

Had to remove the preceding left facing caret "<" to get the above to paste.

[jrobi-atx]

Past two mornings when I start up my workspace, the issue has not happened (have not had to reset my filters)....the main thing I have not done si stop the application the nite before while the floating filter tabs are still floating. I have been resetting them back into the main console window. Can't say that is the only time when it happens, but closing the app with floaters seems to definitely be an issue.

Again, this does not explain losing the settings when I have set things to "portable mode" since I figured portable would only write its settings to its own directory but does seem to be a vector. Also, when I add a new highlighting configuration to Instance1 while Instance2 is still running, then Instance2 will immediately get the update (for Instance1) as soon as I hit Apply/OK.

Will keep at it to help nail it down. Thanks again.

[Hirogen]

since I figured portable would only write its settings to its own directory but does seem to be a vector.

I have to check, but I don't think I implemented the session settings for portable mode, this might explain it.

reopen but after a reboot,

Reboot of the Machine or Logexpert? If machine, temp files are sometimes deleted, if logexpert, it might be a bug

[jrobi-atx]

Apologies for not being clear-er.

I meant reboot of the machine....I typically reboot my machines on the weekend...not during the week unless there is a problem...which sometimes happens on my main laptop. So what I meant to say was that if there is a dependency for the session-saving stability on something that is stored in the temp files, it may be being deleted by whatever Windows does during/immediately-after the reboot.

Pretty sure I've seen wonky behaviour during the week (without a reboot) but again, that may be due to me closing out an LogExpert session with windows still floating. But can't be 100% sure.

[Hirogen]

I meant reboot of the machine....

Ok, then I know what the problem is :)

[jrobi-atx]

Something else I am noticing...I have a job that I use to archive the logs from last week so that the shares are open for the logs from this week...and the Logging instances I use have less data to sort though. Today I started things early just to have a bit more control to observe things.....so the instances where up and configured before the archive job ran.

What I noticed is that the windows from last week stay open but clear of logging data (that was there prior to the archive job running)...whereas the filter windows keep the data that they filtered before the logs where removed.

So this means that at least part of the issue is that the data from the generated temp files are a dependency to enable the filter windows to restart after a reboot or after the temp logs have been deleted/edited whatever.

So seems like there are potentially two sets of potential issues that affect the behaviour I've reported:

Settings and Potable mode.

1. The settings files seem to store/import references to files even when you deselect everything expect "Highlight Settings" when importing settings info from another instance/environment.

2. The persistence files seem to save information from other instances when saving with multiple instance open--even though I am using aliases so that each open instance is opening a uniquely named file.

3. The "portable mode" does not completely silo an instance's settings to itself.

Filter-Window Instability.

1. The call out of the filter windows (from past sessions) are affected by the issues above whether or not you use a common location like My Documents or not. Since the filter windows are affected by the persistance files "*.lxp" (as well as the temp files), *.lxp files containing info from other open instances closing may have their related filter info overwritten by the closing of another window.

2. Any molestation of the "backing" temp files will affect the ability of the filter windows to open successfully.

That's all I got for now. Please let me know if any of the above is unclear.

[jrobi-atx]

Another observation....so yesterday I brought up my two instances on my main laptop for the first time after their weekend reboot. The update from two days ago where I brought up the instances before the archive job is another box--which I try not to touch during the week.

Anyway, on my main laptop, none of the instances came up correctly (like they did last week) and even my backups did not help. I was able to load a saved session on the first instance....the first one I bring up. But the backups of the second instance did not respond to any of the saved sessions that I used.

Given the relative ease of what happened on Sunday when I brought things up early on the other laptop, I was not expecting this. Therefore, I got everything set backup manually on the 2nd instance yesterday on my main laptop....ran it all day. This morning, I brought instance 1 and 2 as per usual....everything worked. And then I rebooted my main laptop after verifying everything worked.

After the reboot of my main laptop was complete, I brought up instance#1 and instance#2 without incident--all filters restored automatically.

So notwithstanding the details, I provided on Sunday, starting to think that the issue may also be impacted by the filters ability to access/restore/retrieve the data represented by the line number information.

As I mentioned, I have an archive job that moves the logs from last week before the beginning of the current week so I can keep the info separate and prevent tons of increasingly old data from having to be loaded by the loggers.

So due to the behaivour of my main laptop, I think that if the logs are their but do not have as many lines as they did when the instances of LogExpert last loaded them, that causes some kind of error condition that is not handled well by the current configuration.

Thanks again.

[jrobi-atx]

This will most likely be my last update for the week...I should have noticed this before, but when I have multiple instances of LogExpert up, and switch over to Task Manager in "Process" Tab., they all go under the same "parent instance" (the instance in the first directory that was brought up)..And there is only one entry for LogExpert for all of them on the "Details" tab. So the parent folder info (image path name) ends up becoming untrue for the instances you bring up after the first.

I am contrasting this observation with the behaviour of say "NotePad.exe" or Adobe Acrobat. It does not use multiple instances/folders but it does individualize the separate Windows.

Good luck and let me know if you need anything to help progress this issue.

[Hirogen]

This will most likely be my last update for the week...I should have noticed this before, but when I have multiple instances of LogExpert up, and switch over to Task Manager in "Process" Tab., they all go under the same "parent instance" (the instance in the first directory that was brought up)..And there is only one entry for LogExpert for all of them on the "Details" tab. So the parent folder info (image path name) ends up becoming untrue for the instances you bring up after the first.

I am contrasting this observation with the behaviour of say "NotePad.exe" or Adobe Acrobat. It does not use multiple instances/folders but it does individualize the separate Windows.

Good luck and let me know if you need anything to help progress this issue.

There are multiple things going on.
Please check if "Lock instances" and / or "Allow only 1 Window" are activated

Another thing, since the "Windows 10 Build 16241" multiple instances of the same application are grouped in task manager, this does not mean they are "under" the same root-instance, this is a little bit misleading in the task manager view.

For adding a "unique" header for every instance, please open another "issue" so we can track that separately.

If "allow only 1 window" (currently renaming it to "allow only 1 instance") is activated, you can only start 1 instance of Logexpert and other instances will be blocked, there is currently no "message" to tell the user that this is happening (will be added with one of the next changes).

If "lock instance" is activated (Options => Lock instance), then everything is sent to that instance, there is currently no Message to inform the user. Informing the user of this is a little bit more complicated and not easily changed.

[Hirogen]

#235 adds

• portable folder in application startup path
  • portableMode.json and plugin configuration are saved in this folder
• sessionfiles folder, where all session files are stored for this particular instance