Ejecting USB Device used by AutoIT app

[OhBobSaget]

Hi,

Here's the situation, i am coding an app with AutoIT that get some files of USB thumb drives and copy them to some folder in the C:\ and then ask the user if he wants to remove it afterward... I am running into some problem when trying to eject a usb key that was used with the FileCopy function to copy the files locally.

This particular key can't be ejected because Windows says that there is an handle with The AutoIT App and the usbkey.  This lead me to think that AutoIT does not release everything after running the filecopy function...

I tried various tools  sync ( from sysinternal ) USBDiskEjector (Http://quick.mixnmojo.com) RemoveDrive (www.uwe-sieber.de)

Also tried with $oDrive.InvokeVerb ("Eject")

But i run into a Windows prompt that says that i have to reinsert this key because it was in use by the AutoIT app.

Have you guys been able to cut the link between an USB key and the autoIT app so you can run a successfull  usb eject ?

 

Thank you for you help !

[ViciousXUSMC]

Do you still see your script open in the task area?

If you're eject is part of your script then its still open on the thumb drive unless you copied it off first and ran it locally.

You may need to break your script into two parts, 

One that pushes the working script to @TempDir or something and executes it (Run from the drive)

The other your actual working script lauched from the first, but it will be hooked on the local drive instead of the removable drive. 

 

;Script 1 "Launcher Script"

FileInstall(WorkingScript.exe, @TempDir & "\WorkingScript.exe")
ShellExecute(@TempDir & "\WorkingScript.exe")

;Script 2 "Working Script"

;Do Some Stuff, Some Copy, Etc
;Eject Flash Drive Prompt

 

Edited June 17, 2015 by ViciousXUSMC

[OhBobSaget]

Hi ViciousXUSMC,

Yes, the program has to remain in the tray for further filecopy functions and some other tasks.

The thing starts when the user right click on the tray and select a functionality ( which ask the user for one or multiples files from the usb key ) and then the app copies them to the correct folder.

So there is no way to tell (self) to close the link with the USB key when the transfer is complete ?

I hope not to divide the script in two if possible.

 

[ViciousXUSMC]

As long as your eject code is running from a script on the USB Key that means a file is still open on the USB and Windows can not eject it.

Even though your transfer is done your still holding a file open; its no different than opening a text file from the USB and Windows will tell you that the file is in use until you close the text file except in your case you have a .au3 or .exe open executing a script.

You need all scripts on the USB to be Ended before you can eject so that means your ejection part of the script needs to come from the local disk unless there is another work around I am not familiar with. 

[OhBobSaget]

Thank you ViciousXUSMC,

 

The scripts are not running from the USB key, they are running from the local hard drive.  The script are copying files from the USB to the local hard drive.

Edited June 18, 2015 by OhBobSaget

[rjframe]

Does this occur regardless of whether the user deletes or keeps the files?

The Sysinternals Process Explorer will show you open file handles.

Since you already know it's AutoIT, while your script is running, make sure "View > Show Lower Pane" is checked, then click your script's process in the upper pane. Any open file handles will show in the lower pane as type "File" (you may also want to look at directories). If your files are not listed, the problem will not be with AutoIT.

To find the process with a specific file open, go to "Find > Find Handle or DLL" and type [part of] the file's path in the search box. Any processes with that file open will show in the list.

Edit:

If this is an "I need it working now" project, just calling xcopy or robocopy might be the best solution.

Edited June 18, 2015 by rjframe

[OhBobSaget]

Thank you rjframe,

I already looked and it is AutoIt that keep a handle on the source file that he copied...

Yeah using copy or xcopy is a good idea since it won't be autoIT responsible for the handling the file transfer...

It would have been nice for autoIT to cut the handles when the filecopy function has finished his job...

I think ill go with this solution for now and if anyone has a better solution... Still appreciated

 

 

[Jos]

Is the AutoIt3script stored on that USB thumbdrive as well?

I've tried a script that simply did a filecopy of a file on the thumbdrive to a tempdile and stayed running and was able to perform an regular "Eject USB drive".

Jos

Edited June 18, 2015 by Jos

[OhBobSaget]

My script does not have this behavior... what OS are you running ?

FileCopy really create a handle with the usb thumb drive.

 

I tried on Windows 8 and 7 here

[ViciousXUSMC]

Perhaps post your full code?  That is probably the best chance for anybody to really be able to look deeper into this.

[Jos]

My script does not have this behavior... what OS are you running ?

FileCopy really create a handle with the usb thumb drive.

 

I tried on Windows 8 and 7 here

Win7 x64, but maybe you can answer my question as well?

Jos

 

Edited June 19, 2015 by Jos

[OhBobSaget]

I have finally found that it is not the FileCopy function responsible to the handle on the USB Device...

The function FileOpenDialog is the one responsible

If i use this function to get a list of file to copy from the usb device, the usb device gets locked until i close the AutoIT executable.

Have you guys encountered a problem with this ?  Is there a way to close this handle ?

I tried getting the FileOpenDialog variable to Null or 0 before trying to remove the USB drive...  Still no luck

[hunte922]

I tried getting the FileOpenDialog variable to Null or 0 before trying to remove the USB drive...  Still no luck

Close any files opened by your script with FileClose.

[OhBobSaget]

The script does not open any files.  It only copy the files from a USB drive to a specific location on the local hard drive.

Selecting these files is achieved with the FileOpenDialog function.

The FileClose function seems to be related with the FileOpen function which i do not use in this case.

 

[OhBobSaget]

This last question was answered in another specific thread by @Jos

Thank you !