|
olpanse Posts: 5
05/07/2018
|
Hi,
I wonder if there is a way to close automatically all programs when they were started via a SyMenu session for safety reasons.
Especially when running SyMenu on a thumb drive it can be helpful having an option to "Close all running applications" before removing the drive to avoid data loss when still active programs might writing back information to the unmounted thumb drive.
Any ideas?
Thanks.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
06/07/2018
|
It's a long time feature I should have implemented long ago. I have even a bit of code for testing but it's currently inactive.
I try to escalate the feature priority but I can promise nothing. For now I have a new version almost ready with a lot of graphical improvement.
Anyway thanks for your suggestion.
|
|
|
link
|
|
lupusbalo Posts: 77
08/07/2018
|
"Graphcal improvements"?? I know i'm ridiculouslly outdated but personnally I'd prefer to have smart functions instead of better look
so +1,+1,+1!!!
edited by lupusbalo on 08/07/2018
|
|
|
link
|
|
olpanse Posts: 5
09/07/2018
|
Thanks for letting me know. I'm coming from "Portable Start Menu" where the feature was almost there from the beginning including a True Crypt container support for the whole process. Due to the events around True Crypt the support of it was removed in some release later. So no offense, but I assumed this should be a standard feature for such software like SyMenu. 
Since I want definitely move to SyMenu I'll try to code a shell-based script myself solving this issue for me in the meanwhile. Since I want to include a Vera Crypt container it's not that simple. :|
Thanks.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
10/07/2018
|
My two cents? Please wait, probably this feature will be release with the 6.06 well at least the autoclosing part.
Actually it is curious how this feature has been pushed back for so long.
The SyMenu evolution has been strange. It's born as a portable menu launcher, but the users almost immediately have started to used it in fixed drives as a Windows start menu replacer. And naturally they started asking features unrelated to a portable application but more bounded to a start menu.
Then the SPS has come and SyMenu has become more an application hub than a launcher. So the focus has been moved again in another direction.
But you are right, the feature you request is essential for the (few) users still using SyMenu in portability. So you'll have it ASAP.
BTW just in case you would write a script for this, how should it work?
I think there are two possibilities:
1) maintain a list of launched process and, at closing time, close them all;
2) at closing time check for all the SyMenu child processes and close them all.
I would be oriented to the latter one but I don't know how reliable this method could be.
|
|
|
link
|
|
olpanse Posts: 5
18/07/2018
|
Hi there,
many thanks for taking care of it. I really appreciate it. Also thank you for the historical insights of SyMenu development. 
I did a shell script solution working quite well for me at the moment. The script will look for certain processes on specific drives and will kill these automatically when SyMenu is closing. I preferred this over looking for child processes of SyMenu because it might be possible that some processes are started from these drives but not directly via SyMenu.
Nevertheless I'm looking forward seeing your implementation in action. Since my scripts are working so far, there is no need for hurry. I'm also curious about the UI improvements you are currently working on.
Thanks again!
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
18/07/2018
|
How do you manage to close the applications that have a launcher themselves?
Take Mozilla Firefox Portable as an example. It has a process called FirefoxPortable.exe and some sub processes called Firefox.exe.
The right way to close Firefox Portable is to close the children processes so that the main process closes by itself.
If you close the parent process before the children you are not granted that all the programs clean up everything as they should do.
Maybe you don't see this effects on Firefox but the problem is quite common in the portable world and there are so many programs that use this schema (a launcher and one or more separate processes).
If you don't follow the right closing sequence you'll risk to have unwanted registry keys, files, and other traces all over your machine.
|
|
|
link
|
|
olpanse Posts: 5
18/07/2018
|
I'm using the "taskkill" command with the option /t. This should perform some kind of tree killing and minimize the risks your are describing: https://ss64.com/nt/taskkill.html
But I agree, my handling isn't perfect at the moment: Sometimes some processes are hanging and are not killable by default. For this I'm forcing them to kill (/f). This is actually a bit risky and might lead to side effects you are describing, because some data might not be written back to disk. I think the best way of handling it some kind of loop asking the user what to do when processes are not killable. PorableStartMenu was more or less behaving like this.
|
|
|
link
|
|
Gianluca Administrator Posts: 1274
18/07/2018
|
From the Taskkill documentation:
/T - Tree kill: terminates the specified process and any child processes which were started by it.
It would be nice to know if the killing process starts from the child or from the parent because the portable programs prefer the first approach.
Anyway I think my solution will be softer than yours.
SyMenu will ask to any process it started (children process) to close. I can't embrace your approach to close all the programs from the unit where SyMenu is located to avoid unwanted killing.
If a process has got a child I'll ask the child to close itself because this is usually enough to close the parent too and, for sure, it closes the two processes in a safer way.
When a process refuses to close, I infer it's because it needs the user to take a decision about the data. Typically, in this situation, a text editor asks if you want to save the changed document. I think I wont insist on it, if the nice request fails I will stop trying.
Another problem will be for any program opened with highest privileges than SyMenu. They simply don't close but probably you've already known that because it's not a SyMenu limit but a Windows security.
Unfortunately when I develop a new feature my approach must be prudential to avoid problems with the thousand of configurations the users have with their SyMenu.
|
|
|
link
|
|
olpanse Posts: 5
19/07/2018
|
Gianluca wrote:
From the Taskkill documentation:
/T - Tree kill: terminates the specified process and any child processes which were started by it.
It would be nice to know if the killing process starts from the child or from the parent because the portable programs prefer the first approach.
I assume that this would kill the childs first, but I'm not absolutely sure of it. I didn't find any detailed information yet, so I've to test it out myself to be sure.
Gianluca wrote:
Anyway I think my solution will be softer than yours.
I totally agree. For me it's just a workaround solution having this script. It's working for me quite good, because I usually close all portable tools like Firefox manually before unmounting the drive. Only few (background) processes from non-critical processes might still be opened at this time.
Gianluca wrote:
I can't embrace your approach to close all the programs from the unit where SyMenu is located to avoid unwanted killing.
I think should be okay in the very most scenarios. I'm a bit cautious, so a implemented the way I described. I tend to have experimental and non-standard-portable setups, so there is a risk that processes aren't spawned from SyMenu directly. But I would see how your approach is working for my, though. I'm looking forward to test it out.
Gianluca wrote:
Unfortunately when I develop a new feature my approach must be prudential to avoid problems with the thousand of configurations the users have with their SyMenu.
Sure, I fully understand and it's good development practice. So take your time.
|
|
|
link
|