Safely Remove Flash Drive

[JRB-Bldr]

I have written a small VFP utility that writes data files out to a Flash Drive.
It is pretty simplistic and works just fine.

But when the write operation is complete the user, more often than not, just 'jerks' the Flash Drive out of the USB port on the workstation.
When they do this they most often do not use the OS to set up for Safely Removing the Flash Drive.
The result of removing the unit while under power is that it occasionally corrupts and/or damages the Flash Drive.

What can I use within my VFP utility to 'Power Down" the Flash Drive and make it safe to physically remove?

Any advice/suggestions you might have to offer would be greatly appreciated.

Thanks,
JRB-Bldr

 

[Mike Lewis]

Don't know. But would it be feasible to arrange for the user (or the user's IT people) to disable Windows' write buffering feature for this drive? In other words, so that it always physically writes the data immediately, rather than buffering it for later.

Maybe I'm talking rubbish. But, if it is possible, it should avoid the problem.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

If you use COPY FILE code after it only occurs after files are copied. But that can still only mean the job of VFP is done, not of the file system/OS. As Mike indicates there are drive buffers, like code and data is cached from RAM to Level2 and Level1 cache in CPUs, the route to HDD has other caches of drive/controller, and aside of that there is OS file caching. All this is beyond your control and the best thing you can do is follow Mikes advice and see whether there are such USB drive options. The typical normal user will not have the rights to look into that detail, though.

Bye, Olaf.

 

[JRB-Bldr]

Mike - Thanks for the reply
I think that the problem arises not during the write process (buffered or not), but rather as a result of 'jerking' the unit out of the USB port while under Power.

After some web searching I see that someone recommends using the Windows CM_Request_Device_Eject function.
I find some C++ code for that at:

https://msdn.microsoft.com/en-us/library/windows/hardware/ff539806(v=vs.85).aspx

But I am not sure how to write that in VFP code.

Alternatively News2News.com has a function: CM_Request_Device_Eject_Ex
There is is shown that after the Declatation

DECLARE INTEGER CM_Request_Device_Eject_Ex IN setupapi;
    INTEGER dnDevInst,;
    INTEGER pVetoType,;
    INTEGER pszVetoName,;
    LONG ulNameLength,;
    LONG ulFlags,;
    INTEGER hMachine

Where:

Parameters:
dnDevInst
Caller-supplied device instance handle that is bound to the machine handle supplied by hMachine.

pVetoType
(Optional.) Can be set to NULL.

pszVetoName
(Optional.) Can be set to NULL.

ulNameLength
(Optional.) Caller-supplied value representing the length of the string buffer supplied by pszVetoName. This should be set to MAX_PATH.

ulFlags
Not used.

hMachine
Caller-supplied machine handle to which the caller-supplied device instance handle is bound.

Use it something like this way:

nResult = CM_Request_Device_Eject_Ex(oDevice.devinst,0,0,0,0, THIS.hMachine)

But where, in this example code line, are the function's parameters coming from (oDevice.devinst & This.hMachine) ?

There also seems to be a free 3rd party utility that works on the Command Line level: RemoveDrive (

http://www.downloadcrew.com/article/26002-removedrive

)
But that necessitates having the user(s) install a 3rd party tool.

Thanks,
JRB-Bldr

 

[Olaf Doschke]

If you ask me, this won't help much, because if you do that after you did COPY FILE, you still don't know when the files are really written.
If you do it right away the request to eject might simply be denied by the OS, as often happens, if you do that manually.

Virus scanners are again an annoyance for us developers and the end users, as they scan thumb drives with priority as it seems to me. And that might hinder ejecting, even if your files are all there already.

The best thing to do is really educate users about the windows feature and also what they should look out. Eg even a normal user might suspend virus scanning on a drive, so it can be manually or programmatically ejected. But in the end to me this a user action, and nothing you automate.

Bye, Olaf.

 

[JRB-Bldr]

After the COPY FILE, the utility waits a short while and then does a IF FILE(<fully-pathed filename written>) to ensure that the file(s) exist on the Flash Drive.

My intent was to do the RemoveFlashDrive() code after that command had been executed and the file was confirmed to exist on the Flash drive.

Unfortunately, as we all know and have had experience with, 'educating' the users is not always effective for one reason or another.

Thanks,
JRB-Bldr

 

[DSummZZZ]

Take a look at CM_Get_Child_Ex and CM_Get_Sibling_Ex. May be helpful.
However, my 2 cents, one glaring problem I foresee is different drive letters. USB drives have many different names, types, etc. And depending on what port they're plugged into, they may get a different driver letter assigned. I think it would be a monumental programming task to eject the proper device from the proper port or drive letter.


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[DSummZZZ]

As per usual, 'News2news' (very valuable resource) has an example too:

http://news2news.com

-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Olaf Doschke]

> after that command had been executed and the file was confirmed to exist on the Flash drive
Well, and there you still only get indefinite answers from the OS about the file state. If COPY FILE is done FILE() always returns .T., besides ADIR(laDummy,"X:\folder\Filename")=1 is a better check.

In my experience you don't get around educating the users.

Bye, Olaf.

 

[craigber]

It *may* not be necessary to do the safe eject. Things changed in Windows 7.

http://www.howtogeek.com/118546/htg-explains-do-you-really-need-to-safely-remove-usb-sticks/

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Mike Lewis]

What that article seems to be saying is that the "quick removal" option is now the default (since Windows 7), so you are safe to remove the device without explicitly ejecting it (provided it has actually finished writing, of course). The problem is that you can't be sure if the user hasn't changed the setting to to "better performance".

I wonder if it would be worth displaying a message during and after the copying of the files. The message would tell the user not to remove the drive. After, say, two or three seconds, you would replace the message with one that says it is now safe to remove the drive. That should give Windows plenty of time to do the physical write, and wouldn't greatly inconvenience the user.

Just a thought.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

To really be sure you better read back a file and compare content with original.

Mike, JRB-Bldr said "the utility waits a short while and then does a IF FILE...", so that idea to wait already is implemented.
I have done writing to client side USB drives shared to a TS from the TS via addressing \\tsclient\F\... and it works, but it really has to be taken with caution. The situation doesn't differ much to a local write, it just takes a while longer and users are impatient. I've seen corrupted sticks.

The quick removal policy helps, but only after all data is written. It can still be deadly to remove a thumb drive, while it's been written to.

Bye, Olaf.

 

[dmusicant]

Even using Win7, I some times bother to EJECT my USB flash drives... i.e. when I'm concerned, when it's important that nothing goes amiss. Sometimes I'm informed that the device is busy and can't be ejected. In that event I do not jerk it out!