EjectUSB
If Program A hangs, that just fulfills the wait period and it will get forcibly terminated. And after 5 seconds, yes it would forcibly terminate everything still running, but that's the entire point of TimeToWait. If you want to make sure EjectUSB isn't killing anything early you can set TimeToWait to 1000, to make sure everything has a chance to close gracefully. If everything does close just fine, it won't wait 1000 seconds, it will continue as soon as it detects everything's closed. However, if a program does hang, it will wait 1000 seconds before trying to terminate it. There isn't a perfect solution here; TimeToWait is a guess at when to kill off a program that has taken too long to close.
I'd like to emphasize all programs are told to close BEFORE any waiting occurs, so one program hanging won't prevent others from getting a chance to shut down properly.
Originally EjectUSB did wait on each program individually. With a TimeToWait of only 5 seconds, if EjectUSB was trying to close a mere 10 hanged programs, that would've taken 50+ seconds, which is unacceptable. EjectUSB was designed to eject the drive as quickly as possible, not to manage programs that the user hasn't saved data in yet. This means closing everything to stop read/write activity to the drive and initiating safe removal calls. It's meant to be human accomodating (you set how long you're willing to wait) not computer accomodating (the computer tells you how long you're going to wait). This is a major point of EjectUSB's design philosophy.
If you frequently use programs that take a while to close, increase the TimeToWait value. 30 is probably enough time for nearly anything and 30 seconds isn't TOO excrutiating of a wait if somethnig does hang.
Queue
I'd like to emphasize all programs are told to close BEFORE any waiting occurs, so one program hanging won't prevent others from getting a chance to shut down properly.
Originally EjectUSB did wait on each program individually. With a TimeToWait of only 5 seconds, if EjectUSB was trying to close a mere 10 hanged programs, that would've taken 50+ seconds, which is unacceptable. EjectUSB was designed to eject the drive as quickly as possible, not to manage programs that the user hasn't saved data in yet. This means closing everything to stop read/write activity to the drive and initiating safe removal calls. It's meant to be human accomodating (you set how long you're willing to wait) not computer accomodating (the computer tells you how long you're going to wait). This is a major point of EjectUSB's design philosophy.
If you frequently use programs that take a while to close, increase the TimeToWait value. 30 is probably enough time for nearly anything and 30 seconds isn't TOO excrutiating of a wait if somethnig does hang.
Queue
Ok, as it sends messages to all programs first, there's no problem.Queue wrote:If Program A hangs, that just fulfills the wait period and it will get forcibly terminated. And after 5 seconds, yes it would forcibly terminate everything still running, but that's the entire point of TimeToWait. If you want to make sure EjectUSB isn't killing anything early you can set TimeToWait to 1000, to make sure everything has a chance to close gracefully. If everything does close just fine, it won't wait 1000 seconds, it will continue as soon as it detects everything's closed. However, if a program does hang, it will wait 1000 seconds before trying to terminate it. There isn't a perfect solution here; TimeToWait is a guess at when to kill off a program that has taken too long to close.
I'd like to emphasize all programs are told to close BEFORE any waiting occurs, so one program hanging won't prevent others from getting a chance to shut down properly.
If it could detect save dialogs and wait for them, it would be perfect.
I just wanted to add that another possibility to WM_CLOSE is to send the WM_DESTROY message. Some apps (like Sandboxie) will respond to the DESTROY message instead of the CLOSE message. Perhaps you'd want to implement that in an INI file somewhere so a user could experiment and see if it works better for a particular app.
seems everyone is liking the application:
http://www.freewaregenius.com/2008/07/2 ... e-removal/
Wow you have created a program that everyone is finally catching onto, if only they had read your post back in April!!!
Hows 1.4 looking?
http://www.freewaregenius.com/2008/07/2 ... e-removal/
Wow you have created a program that everyone is finally catching onto, if only they had read your post back in April!!!
Hows 1.4 looking?
Last edited by guinness on Tue Jun 28, 2011 4:28 pm, edited 1 time in total.
Oh holy crud, 1.3's up to 15k downloads already. 1.0, 1.1 and 1.2 together got 10k downloads and I was REALLY proud of that.
1.4's still just a list of things to work on, right now I'm working on the documentation for (and testing) hybrid batch scripts. I'm hoping to have that ready sometime mid next week; I've been very busy, and EjectUSB just gets worked on in my free time.
1.4 will likely contain new keywords for the scripting, I'm gonna look into WM_DESTROY, will improve graceful program closing and compatibility with programs with hidden windows (<- this is actually done already), an improved dead icons in the system tray cleanup routine, ejection pausing for save dialogs... I think covers what I have planned so far.
In particular I need to figure out how to detect more specific information about drive types, particularly if something is a flash card reader.
Oh, and http://www.ejectusb.com now points to the PAR blog entry for EjectUSB. I'll get a proper website made for it eventually...
Queue
1.4's still just a list of things to work on, right now I'm working on the documentation for (and testing) hybrid batch scripts. I'm hoping to have that ready sometime mid next week; I've been very busy, and EjectUSB just gets worked on in my free time.
1.4 will likely contain new keywords for the scripting, I'm gonna look into WM_DESTROY, will improve graceful program closing and compatibility with programs with hidden windows (<- this is actually done already), an improved dead icons in the system tray cleanup routine, ejection pausing for save dialogs... I think covers what I have planned so far.
In particular I need to figure out how to detect more specific information about drive types, particularly if something is a flash card reader.
Oh, and http://www.ejectusb.com now points to the PAR blog entry for EjectUSB. I'll get a proper website made for it eventually...
Queue
Last edited by Queue on Sat Jul 26, 2008 7:24 am, edited 1 time in total.
It's the inane name I'm using for specialized batch file support for EjectUSB. The first line of the batch file contains special keywords that EjectUSB reads, and based on these, the normal contents of the batch file are executed by EjectUSB at a specific time (namely, before or after programs are closed) or not at all if you use the keywords to do all the work and don't need to run the batch script itself.
http://www.pocketappreview.com/main/med ... C_beta.zip
Here are 4 example scripts to work with TrueCrypt. None of them will work without at least renaming them from EjectUSB_TC#.bat to EjectUSB.bat (or whatever you rename EjectUSB.exe to). TC0 requires you to edit the first line and specifically set the TrueCrypt volume letter. TC1, 2 and 3 all automatically detect the TrueCrypt volume for you. TC3 is the same as TC1 except it also performs cleanup on the drive TC is located on (instead of just on the TrueCrypt volume itself); useful if you don't keep EVERYTHING in your TC volume.
None of them do any TrueCrypt specific registry cleanup yet. The keywords to do that are ''delregval'' and ''delregkey'' but I haven't yet researched exactly which values/keys would need to be removed. I keep putting that off but I'll get around to it eventually.
Queue
http://www.pocketappreview.com/main/med ... C_beta.zip
Here are 4 example scripts to work with TrueCrypt. None of them will work without at least renaming them from EjectUSB_TC#.bat to EjectUSB.bat (or whatever you rename EjectUSB.exe to). TC0 requires you to edit the first line and specifically set the TrueCrypt volume letter. TC1, 2 and 3 all automatically detect the TrueCrypt volume for you. TC3 is the same as TC1 except it also performs cleanup on the drive TC is located on (instead of just on the TrueCrypt volume itself); useful if you don't keep EVERYTHING in your TC volume.
None of them do any TrueCrypt specific registry cleanup yet. The keywords to do that are ''delregval'' and ''delregkey'' but I haven't yet researched exactly which values/keys would need to be removed. I keep putting that off but I'll get around to it eventually.
Queue
false positive??
I am using avast and it detects a trojan in the new download.
Is this a common issue or is this just me?
Is this a common issue or is this just me?
- spacemonkey
- Posts: 42
- Joined: Wed Jun 06, 2007 11:09 pm
Obviously I've been gone for eons (3 or 4 months at least). Now that my life's a little less hectic, I'm going to be trying to spend more time around here at TPFC, portable app'ing in general (the stuff on my flash drive has been a godsend the past few months), and getting more development done on EjectUSB. I had a little time recently to work on the latter and should have EjectUSB 1.4 done and available before Christmas.
I know about the Avast issues and can assure you it's a false positive; my test builds of EjectUSB 1.4 haven't been triggering Avast, though they do trigger Ikarus. Scrambling the UPX header avoids the Ikarus false positives, but I'm not particularly happy with having to do that. =/
Queue
I know about the Avast issues and can assure you it's a false positive; my test builds of EjectUSB 1.4 haven't been triggering Avast, though they do trigger Ikarus. Scrambling the UPX header avoids the Ikarus false positives, but I'm not particularly happy with having to do that. =/
Queue
Drop Avast an email.Queue wrote:Obviously I've been gone for eons (3 or 4 months at least). Now that my life's a little less hectic, I'm going to be trying to spend more time around here at TPFC, portable app'ing in general (the stuff on my flash drive has been a godsend the past few months), and getting more development done on EjectUSB. I had a little time recently to work on the latter and should have EjectUSB 1.4 done and available before Christmas.
I know about the Avast issues and can assure you it's a false positive; my test builds of EjectUSB 1.4 haven't been triggering Avast, though they do trigger Ikarus. Scrambling the UPX header avoids the Ikarus false positives, but I'm not particularly happy with having to do that. =/
Queue