Opening and closing another copy stops the ongoing process

[Noneneeded2]

Hey, great app

The issue is when I'm compressing a huge folder, then open another copy of the app to compress some other folder, when the second compressing is done and I close the app, the first huge folder process stops, doesn't use any hard drive time/CPU.

Thanks for your efforts

[rjgotten]

Yeah; it would do that. The author's idea of a graceful shutdown on close is to use taskkill to force a shutdown of compact.exe, potentially leaving you with a half-corrupted file-system in the process.

As an added bonus; the program doesn't even bother to use the unique process ID. It filters based on image name, which means any and all open instances of compact.exe running on the local system are killed.

https://github.com/ImminentFate/CompactGUI/blob/09ae65b958e8cb15c9fac55301ee14674028c0b5/WindowsApp1/Compact.vb#L1121-L1135

This piece of software is - quite evidently - not ready for general use.

[TjReiny]

well this can be changed easy i guess

[rjgotten]

well this can be changed easy i guess

Not really.

The program currently doesn't call compact.exe directly via the Process class. It starts cmd.exe instead and then uses WriteLine to send commands to it over the standard input stream.

If you're looking to narrow the target for the taskkill operation; there's no way to know what the process ID of the corresponding compact.exe is. And if you're looking to avoid the taskkill in its entirety; there's no knowing when compact.exe will be done, short of monitoring the standard output stream for any known output upon completion.

Really; the entire guts of this thing should be axed and it should be rewritten to use Process to directly call compact.exe and not go the long way around via cmd.exe, which is just; well-- crazy, really. And then it should prevent users from fully closing the application until running compact.exe tasks have finished. Closing the application could ofcourse already close the main UI, but it would need to leave some kind of progress indicator going to indicate remaining activity before full closing to users.

[TjReiny]

@rjgotten us design skills seem to be on pair to mine, but i just see that it have to be rewritten a bit. Telling that it should be axed dont motivate the developer, he might miss knowledge and use the cmd path to get the verbose messegnes. he could rewrite and kill the gui insted the the process and close the cmd everytime when he have done analyze/compress individual and prevent the user to launch multiple insances of CompactGui. That seems lesser work to me from his POV.

[Iridium-IO]

@rjgotten While inflammatory, you do have valid concerns. There's really no need to be using cmd.exe anymore, but it's been left behind because I haven't got around to code cleanup in a while (I've been really busy, so changes and fixes at the moment have been in spare time)

• I used it at the very start because it was easy to monitor and feed alternative arguments to cmd.
• Then I took it out and called compact directly, but went back to cmd to sort out localisation issues (I was very new to this, having never had to work with system encoding before, so the code isn't great).

Now as you mentioned (and I am well aware of), calling a process through cmd causes you to lose sight of the processID, so you can't target just that one.
So instead, here comes the "idea of a graceful shutdown" - taskkill() every compact.exe running. I admit this isn't great, but I worked off two assumptions:

• Only one instance of CompactGUI will be running at a time (Which has failed spectacularly, seeing as I must have accidentally reverted single instancing at some point)
• A commandline compact and CompactGUI will not be running at the same time.

Now if you have a look at the code that calls that function, you'll see if checks to make sure the current UI isn't already running an action. If it is running, then it throws a warning that you have to commit to before it kills the compression. I chose this route at the time I was working on localisation because it would limit the amount of core changes that were required, so it wouldn't introduce new bugs.

 If isActive = 1 Then

            If MessageBox.Show _
                ("Are you sure you want to exit?" & vbCrLf & vbCrLf & "Quitting while the Compact function is running is potentially dangerous." _
                 & "Continuing to close could lead to one of your files becoming stuck in a semi-compressed state." _
                 & vbCrLf & vbCrLf &
                 "If you do decide to force quit now, you can potentially fix any unreadable files by running Compact again," _
                 & "selecting the 'Force Compression' Checkbox and then running uncompress on the folder." & vbCrLf & "Click Yes to continue exiting the program.",
                 "Warning!", MessageBoxButtons.YesNo, MessageBoxIcon.Exclamation, MessageBoxDefaultButton.Button2) <> DialogResult.Yes Then

                e.Cancel = True

            Else
                Try
                    LetsKillStuff()
                Catch ex As Exception
                End Try
End If

So if something is already running, it's not just going to go ahead and kill it, which I thought was a reasonable way around the issue - someone wants to cancel it, warn them that cancelling isn't going to be clean, and then give them the option. I even called the function "LetsKillStuff()" to highlight that it's not a great idea.

Works in most situations? Yes. Good code? No.

Which brings us back to the matter at hand - multiple windows open. Honestly, it was supposed to be single-instanced, and a while back I must have toggled it back by accident. So that would be easy to 'fix' - just stop users from opening more than one instance, problem solved. Or I could add another capture to the kill function to check if the number of compactgui processes is >1.

For now, I'll just switch it back to single instancing, a bandaid fix until I have more free time to sort this out properly.

Never fear, I don't plan to use cmd in the long run, as it's a bloody stupid way of going about it. Just have a look at this entire section It will make you cry how inefficient it is.

[TjReiny]

like i told. im glad that i get no rebackup.

[Iridium-IO]

@TjReiny @rjgotten do you want to try this version? It should be much safer, and multi-instancing should work fine since it's calling and quitting its own process now - it also won't force kill on exit, but rather wait for the current file (not folder) to finish processing and then close. (The source is under the development branch)

@Noneneeded2 if you want to give this a go too, that would be great :)

CompactGUI.zip

[Noneneeded2]

thanks!

[Iridium-IO]

@Noneneeded2 it might be better if you use the one from the downloads page instead :)