It cant be TrueCryt as I am constantly dismounting, could it be because you delete the MRU reg keys or mounted devices?

It shouldn't be, but you can test. Copy your EjectUSB.ini file to the same folder as EjectUSB_beta.exe, rename it to EjectUSB_beta.ini and change DoNotClean=0 to DoNotClean=1. That will prevent EjectUSB from deleting anything from the registry.

I honestly can't think of anything EjectUSB's doing that could be causing it, as all EjectUSB is currently doing as far as TrueCrypt is concerned is running TrueCrypt.exe /q /d%1

Open EjectUSB_beta.bat in a text editor and change
TrueCrypt.exe /q /d%1
to
TrueCrypt.exe /d%1 /f /q /s /w
and see if that makes any difference as well, if you would.

Queue

A day later than I meant for it to be, but here's the second beta:
Link removed, version 1.3 released.

This is a release candidate for version 1.3. Known bugs are fixed, Subst and EjectMedia.exe support is in, system drive fail-safes are silent for better support of scripting, and the hybrid batch scripting is complete (barring future additions).

Full TrueCrypt support (unmounting and cleaning up the registry) should hinge on getting the kinks worked out of the script file (the hybrid batch script).

Why am I calling it hybrid batch scripting? Because the file is mostly a batch file, but the first line contains keywords EjectUSB reads to perform specialized functions.

You should no longer need to run EjectUSB_beta.exe with special command line switches guinness, just throw the exe and bat file in the same folder as TrueCrypt.exe, make sure the ''target'' value in the bat file is the correct letter for your TrueCrypt volume (I set it to ''y'' by default in this beta), and give it a shot.

Queue

Sorry about the late reply had other stuff yesterday. I have tested beta2 and its alot better, whatever you did had some effect on the way it handles the dismount. but I did a comparison on the registry before and after and couldn't see any modifications.

I take it that its just me testing?

Also more on the aesthetics side I have 1 remaining icon in my taskbar so that code you have implemented to refresh the taskbar icons might need a delay applied? again i have tested this three times in a row and same icon was there.

Will you be releasing the source code on the full version of 1.3?

Source will be included (I'll always release it with full releases), I just haven't been on these betas because some areas are unfinished or commented out, and I didn't want someone making adjustments and accidentally enabling something that isn't fully functional (in case it's dangerous).

Does beta 2 still have the problem where you need to restart before you can remount the TrueCrypt volume? Do you get error messages anymore?

Which icon is left in your system tray, and do others clear properly? If I can figure out any improvements to the system tray cleanup, I'll certainly make them. Cleanup occurs after everything's closed, so a delay shouldn't be required to catch dead icons. Does your system use icon hiding, and is your icon hiding/unhiding slow (more than 1 second for all icons to show)? Like you pointed out, I'm relying on someone elses script to accomplish that.

Registry cleanup specific to TrueCrypt STILL isn't implemented, so yes, no changes before and after are to be expected; that is the final step after I have it unmounting properly, but the script support is there for it, so it should be trivial to add.

Edit: and no need for apologies. You're a volunteer and I really appreciate everything you've helped me with. Which reminds me, I gotta get everyone who has helped me test listed in the documentation!

Queue

beta 2 seems to be fine. you probably didn't change any code but its not deleting reference to the Y: drive. The icon doesn't clear after the program has been running for a while (icon is CAFE PortableApps version) but does if its running for 1 minute. The dismount is fine now

I am a bit reluctant to have the reg keys of Truecrypt cleaned up because after thinking about it i have Truecrypt installed as well (didn't about 1 week ago) but I think this would have some effect.

I hate to say this but for a while I will keep the EjectUSB.exe on my Y:\ drive to ensure all programs are fully stopped and dismount using my script. (I hope you aren't offended!) after time I will move across to placing in the directory of the TrueCrypt.exe

As for future releases I would be happy to help with ideas. What else have you included in version 1.3? I thought you were going to implement substitution?

No, I'm not offended at all, use EjectUSB how you want.

That was my main concern with cleaning up after TrueCrypt, is some people will have it installed and won't want it removed from the registry. The capability to clean up after it will be there for the stealth purists though.

Un-Substitution is implemented already; if EjectUSB either is told to eject a Subst drive letter, or a location that is Subst'd to another drive letter, it will remove the Subst entries.

So, say you have a folder on D drive called Substitute, and you Subst D:\Substitute to drive X:. If you use EjectUSB on drive D: or D:\Substitute, the Subst reference will be cleared and drive D: will attempt to be ejected. If you use EjectUSB on drive X:, the Subst reference will be cleared and drive D: will attempt to be ejected (since drive D: is the actual ejectable device).

Card reader support is 99% implemented. All I need is a way to detect if the drive letter is a card reader or not to support those dual card/USB drive flash cards.

Queue

2 suggestions:
-Follow this guide. For me it's very important, how is application supposed to save it's data when it's brutally terminated?
-Get rid of orphaned tray icons. ( http://www.autohotkey.com/forum/post-157494.html#157494 )

_________________

Thanks! Those are both really good resources. The second should be a more effective method than I'm currently using for tray cleanup.

The Microsoft article on safe closing is basically what graceful program closing is doing on the first pass. EjectUSB first tries to send close commands to all windows of the program (as if you were clicking the X in the corner of the program yourself) and then waits to see if it successfully closes. The user has the option to increase the TimeToWait value if they want time to react to the ''do you want to save'' dialogs that may open (the default gives them just 5 seconds). After that, forceful termination occurs on any lingering programs. Originally I just did forceful terminations for everything because it was a) fast and b) I assumed I'd save everything before trying to eject. This gives me an idea though... I could add an option for EjectUSB to pause ejection if it detects a save dialog box and continues once its been dealt with... guess that'll be on the plate for 1.4.

1.3's ALMOST ready for release. I've just got a little bit of adjusting left to do.

Queue

I have downloaded 1.3

I will keep the forum up to date of any problems I find! Oh and where do I find handle.exe which is lower than 1.20? as i can only find 1.40?!

Oh, so that's what graceful killing is? The name is correct, but it doesn't work for one of my programs, so I thought that this means something else and that's why I posted the guide.
Not all programs have close buttons. Or visible windows. And my program doesn't receive WM_CLOSE.

_________________

The program doesn't actually have to have a close button to send it a close command (and have it succeed, at least as far as I've seen), however, the program has to have a registered window handle (even if the window isn't visible). So the first two don't matter that much as long as the program at least has an invisible window, some don't though, and there doesn't seem to be anything I can do about that other than fall back on a forceful termination.

When you say your program doesn't receive it, do you mean EjectUSB fails to send it a close command? Does it fit the previous criteria (have at least 1 window, even invisible)?

If a program is, let's say, a portable launcher that runs a program then waits for it to close, you can add the launcher executable to the exclusions list (that's the primary purpose of the exclusions list). This way, when EjectUSB closes the program the launcher is waiting for, the launcher will close automatically and not be terminated (unless it takes too long to close). If the launcher needs more time to clean up, that's what the TimeToWait value is for, and it can be increased to give it more time.


It's pretty damn hard to find versions of Handle older than the current 3.40. Due to license issues with Handle, I can't redistribute, nor should I probably even link to older versions, but I'll tell you I've found versions 3.10, 3.20 and 3.30 by using Google. I think 3.30 was in an anti-malware collection Torrent, 3.20 was was in someone's personal FTP directory, and I can't remember where I found 3.10. 3.20's the best in my opinion.

Queue

Yes, it has a window and doesn't receive WM_CLOSE.
The program is tested well enough to make me sure that the problem is in EjectUSB.


Actually the main purpose of this program was waiting in background for WM_CLOSE or WM_QUERYENDSESSION, then executing a cleanup script, so exclusions list won't help here.
Time...when I will use it, I'm gonna need more than 5 seconds, but currently the program is being terminated immediately, so it's not the case.
PM me if you want to get it for testing.

_________________

One more suggestion.
Waiting for several programs can take quite a lot...how about doing the waits simultaneously?
I'm not sure if AutoIt allows multithreading, but you can simulate it by running several instances of your process.

_________________

TimeToWait is a maximum time rather than per-program for some of the wait phases, so in essence, I am waiting for them simultaneously. Basically, all close commands are sent out at once (technically this is serialized, but it occurs within a second, usually within a tenth of a second, even in a very overloaded situation), then the first wait phase occurs. Though they're checked in order, they're still all timing out at the same time.

Here's an example of how the timing would occur:
3 programs are to be closed by EjectUSB and none of them want to close right away.
Program A takes 1 second.
Program B takes 2 seconds.
Program C takes 6 seconds.
TimeToWait is set to 5.
EjectUSB starts waiting on Program A. After 1 second it's gone so it starts waiting on Program B. 1 second has already passed so it's only 1 more second before Program B has closed and then it starts waiting on Program C. 2 seconds have passed, and after 3 more seconds TimeToWait has been reach and EjectUSB moves on. Even if EjectUSB had started watching Program C first, after 5 seconds it would've hit TimeToWait and moved on.
Say there was no program C; regardless of the order it watches Program A and B, after 2 seconds it will move on to the next step.

Running multiple copies is an unacceptable solution and just not an option with how EjectUSB is built, but also unnecessary.

Queue