I am developing the Windows program that removes specified disk from Windows system.
The action of "removing" does NOT mean unplugging HDD "physically".
It means that the program removes a disk from device node managed by OS.
"disk" what I'm saying is the disk that is managed by disk.sys(PhysicalDrive0, PhysicalDrive1..)
By the way, on usual Linux system, it can be done with a command like below.
echo 1 > /sys/block/sde/device/delete
I want to do same thing as above on Windows by program.
Once I have tried to do it by removing a disk in DeviceManager.
Actually this way could remove USB disk, but this way could not remove SATA disk without rebooting OS.
I want to do it without rebooting.
Is there any way to do it ?
I believe WMI might help you:
wmic logicaldisk delete (check with /? how to use it)
In order to know which ones you have now, launch the following first:
wmic logicaldisk list brief
Related
I have a tedious project coming up. I need to insert an USB flash drive into a computer, then copy over three files to that drive, and then unmount it and repeat 3000 times (literally). I was hoping to come up with some VBScript that can reduce my actions to just
insert the USB flash drive,
double click on the .vbs file,
remove the USB flash drive.
I figure it isn't too difficult to come up with the copy and paste part of the code as long as I am inserting the USB into the same port every time. Is this assumption correct? However, the real problem is unmounting/ejecting the USB drive. Is there any simple VB Script code that can accomplish this?
This was the first Google result for vbscript unmount: Unmounting USB drives
This worked on Windows 7 if the script is run elevated (as an Administrator):
Set shell = WScript.CreateObject("WScript.Shell")
shell.Run "mountvol <drive>: /d"
mountvol is included with Windows.
You could probably even reduce the input needed by polling the drive letter that your USB sticks mount to, and if there is a drive present, copy the files over and then unmount.
Since you're doing this with a thumbdrive, you can put DevCon on it and use DevCon to eject the drive..
http://support.microsoft.com/kb/311272
or you can also try DevEject
http://translate.google.com/translate?u=http://www.withopf.com/tools/deveject/&langpair=de%7Cen
My answer is not very much related but if you are willing to use Linux I would have a full software stack for exactly that. What it does is to hook into the Linux udev system and automatically formats USB pen drives that get connected to certain USB ports, then copies files to the drive, unmounts the drive and informs the user.
We used this to copy data to 500+ merchandise USB pen drives.
The best option I can find is this:
1) open a shell and run mountvol and locate GUID
\\?\Volume{1be3da43-6602-11e0-b9e6-f11e1c50f5b5}\
F:\
2) execute mountvol /p [GUID] in script
Dim eject
Set eject = WScript.CreateObject("WScript.Shell")
eject.Run "mountvol \\?\Volume{1be3da43-6602-11e0-b9e6-f11e1c50f5b5}\ /p"
Set eject = Nothing
The only problem with this method is that it needs administrator access to remove the drive letter. If called by a user it will unmount the drive, in this case leaving an F: phantom. It is safe to remove the USB drive, or you can eject the phantom to remove it.
When I boot up Linux Mint from a Live CD, I am able to save files to the "File System". But where are these files being saved to? Can't be the disc, since it's a CDR. I don't think it's stored in the RAM, because it can only hold so much data and isn't really intended to be used as a "hard drive". The only other option is the hard drive... but it's certainly not saving to any partition on the hard drive I know about, since none of them are mounted. Then where are my files being saved to??
Believe it or not, it's a ramdisk :)
All live distros mount a temporary hard disk in RAM memory. The process is completely user-transparent and is all because of the magic of Linux kernel.
The OS, in fact, first allocates an area of your RAM memory into a virtual device, then mounts it as a regular hard drive in your file system.
Once you reboot, you lose all your data from that ramdrive.
Ramdrive is needed by almost all software running on Live CDs. In fact, almost all programs, in particular desktop managers, are designed in order to write files, even temporary, during their execution.
As an example, there are two ways to run KDE on a Live CD: either modify its code deeply in order to disallow you to change wallpaper etc. (the desktop settings are stored inside ~/.kde) or redeploy it onto a writable file system such as a ramdrive in order to avoid write fails on read-only file systems.
Obviously, you can mount your real HDD or any USB drive into your virtual file system and make all writes to them permanent, but by default no live distro mounts your drives into the root file system, instead they usually mount into specific subdirectories like /mnt, /media, /windows
Hope to have been of help.
It does indeed emulate a disk using RAM; from Wikipedia:
It is able to run without permanent
installation by placing the files that
typically would be stored on a hard
drive into RAM, typically in a RAM
disk, though this does cut down on the
RAM available to applications.
RAM. In Linux, and indeed most unix systems, any kind of device is seen as a file system.
For example, to get memory info on linux you use cat /proc/meminfo, where cat is used to read files. Then, there's all sorts of strange stuff like /dev/random (to read random crap) and /dev/null (to throw away crap). ;-)
To make it persistent - use a USB device - properly formatted and with a special name. See here:
https://help.ubuntu.com/community/LiveCD/Persistence
I'm setting up a test bed where I am testing a device connection across multiple Windows OSs. I can't do it in a VM (cannot virtualize access to device) so I have quite a multi-boot system. I have a script to automate the process, but I want it go ahead and finish, selecting the next OS to boot and run its test.
One problem is that XP/2K3 use boot.ini while Vista and later use BCDEdit. I could manually have two scripts... one for each XP/2K3 to edit boot.ini. And then to BCDEdit for Vista systems. I'd hate having to hardcode each one though, esp if I have to change order and/or toggle off certain OSs depending on the test conditions.
BCDEdit also uses GUID for their entries, meaning setting up on different machines would mean figuring out which GUID to go to next.
Any thoughts or hints? Are there any utilities that help automate this?
I'm assuming your various flavors of Windows are housed on different partitions. Use an Ubuntu LiveCD to install GRUB and write several configuration files, each of which has one OS selected as the default. Make a HD partition for /boot, and store the GRUB configs in the same location.
Each of your Windows partitions will need to install the Ext2 IFS driver, and mount the EXT2 partition you made before as z: or something. Then your test script can do something like:
mountvol z: %bootvolname%
copy /y boot_to_vista_64.lst z:\boot\grub\menu.lst
shutdown -r -f -t 0
%bootvolname% is a bit complicated, and is OS-specific. You'll need to store it with each OS partition, and you can get it by doing mountvol z: /l while that OS is running.
I have to write a bat script for a test scenario where the software that we are testing fails to write to file due to a disk full error. The test script must be automated, so that we can run it on overnight tests, for example. The test script must also work at different computers, so installing a software like a virtual machine wouldn't be the best solution in this case.
How can I simulate that error in a Windows environment?
You could try writing to a full floppy disk.
Edit:
In light of your edited question, you could set up a network share with no disk space quota and write to that. The error will then be produced regardless of the logged on user or machine.
For Windows XP or later:
This command can get the amount of free space for the c:\ drive:
for /f "usebackq tokens=1-5" %%A in (`dir c:\ ^| find "bytes free"`) do (
set FREE_SPACE=%%C
)
Replace c:\ with your drive, as needed.
You can then take some space away from this value so you have a little room to work with:
set /a FREE_SPACE=FREE_SPACE-1024
or however much space you want to keep free.
You can use the fsutil command to create a file to fill up the free space on the disk:
fsutil file createnew c:\spacehog.dat %FREE_SPACE%
Run your test, writing to the drive. After you write 1024 bytes or so you should run out of space.
Download and install TrueCrypt. You can then create a virtual partition of whatever size you want (a couple of megabytes), mount it and then fill it with a couple of documents.
Best Option: Microsoft's consume program
Reasons:
It tests the system disk (vs a separate drive)
It's fast - run the program to fill the disk instantly, stop when no longer needed
It's easy - No creating and deleting files. No extra test partition hanging around. Installation is required, but you can use a simple command afterward.
It's scriptable
Steps:
Install the Windows Server 2003 Resource Kit Tools (Works fine on Windows 7)
cd "%ProgramFiles(x86)%\Windows Resource Kits\Tools" (or whereever it's installed)
consume.exe -disk-space
Command output:
C:\Program Files (x86)\Windows Resource Kits\Tools>consume.exe
Universal Resource Consumer - Just an innocent stress program, v 0.1.0
Copyright (c) 1998, 1999, Microsoft Corporation
consume RESOURCE [-time SECONDS]
RESOURCE can be one of the following:
-physical-memory
-page-file
-disk-space
-cpu-time
-kernel-pool
C:\Program Files (x86)\Windows Resource Kits\Tools>consume.exe -disk-space
Consume: Message: Total disk space: 96049 Mb
Consume: Message: Free disk space: 14705 Mb
Consume: Message: Free per user space: 14705 Mb
Consume: Message: Attempting to use: 14705 Mb
Consume: Message: Reattempting to use: 14705 Mb
Consume: Message: Sleeping ...
Other Options:
Windows 7 has a virtual hard drive feature. Basically do the following: Computer Management > Disk Management > Action Menu > Create VHD > Right click disk and Initialize > Right click
Generate large files (should be instant) until your disk is full using a shell command or Dummy File Generator program. Another prorgram: SpaceHog.
It might seem like a bit much, but one thing I can think of is to use a virtual machine, and set its virtual disk to just big enough to fit the OS on. Fill it with some garbage files to tip it over the edge, then run your program.
Create a secondary partition, fill it with junk and then run your program there.
You could setup a small ramdisk and write to that. See this page for some free ramdisk products.
Create a new user accout, set a quota for it, and use runas to run your app as that user. (not exactly the same as disk full, but should have similar consequences.)
The operating system will respond differently to it's system drive filling than to other drives filling and as such your application will do so too, surely? Simply filling a drive irrespective of what the physical media is used isn't going to be a accurate test.
Can't you mock the file system event for a full disk? Why would you want to wait until the disk is full? Wouldn't you want to monitor disk space periodically and warn the user when the disk is with a percentage margin of filling? Rather than wait until the disk space is terminal simply prevent your application from working until the issue is resolved, not doing so could effect any data IO and be unrecoverable!
If the test has to be a hard integration test then automating a virtual machine, deploying the application and then fill the remaining space with a recursive script is feasible.
Best thing that works on every computer (as testing is not neceessarily done on a dedicated machine) would be a ramdrive/ramdisk that could be set up on the fly.
Only found a Virtual Disk SDK so far see here that maybe could be included in your buzild process.
Different idea: maybe your testing computers could be set up to write to a shared network folder (that is full) mount as a drive?
I have made a modification to the above script to make it compatiable with Windows 7... Essentially adding the switch "/-c" to the for statement. This removes the thousands seperator as fsutil does not like it in the statement.
for /f "usebackq tokens=1-5" %%A in (`dir /-c d:\ ^| find "bytes free"`) do (set FREE_SPACE=%%C)
fsutil file createnew d:\largefile.txt %FREE_SPACE%
use a very small iscsi target
I'm need to find a method to programmatically determine which disk drive Windows is using to boot. In other words, I need a way from Windows to determine which drive the BIOS is using to boot the whole system.
Does Windows expose an interface to discover this? With how big the Windows API is, I'm hoping there is something buried in there that might do the trick.
Terry
p.s. Just reading the first sectors of the hard disk isn't reveling anything. On my dev box I have two hard disks, and when I look at the contents of the first couple of sectors on either of the hard disks I have a standard boiler plate MBR.
Edit to clarify a few things.
The way I want to identify the device is with a string which will identify a physical disk drive (as opposed to a logical disk drive). Physical disk drives are of the form "\\.\PHYSICALDRIVEx" where x is a number. On the other hand, a logical drive is identified by a string of the form, "\\.\x" where x is a drive letter.
Edit to discuss a few of the ideas that were thrown out.
Knowing which logical volume Windows used to boot doesn't help me here. Here is the reason. Assume that C: is using a mirrored RAID setup. Now, that means we have at least two physical drives. Now, I get the mapping from Logical Drive to Physical Drive and I discover that there are two physical drives used by that volume. Which one did Windows use to boot? Of course, this is assuming that the physical drive Windows used to boot is the same physical drive that contains the MBR.
Go into Control Panel
System and Security
Administrative Tools
Launch the System Configuration tool
If you have multiple copies of Windows installed, the one you are booted with will be named such as:
Windows 7 (F:\Windows)
Windows 7 (C:\Windows) : Current OS, Default OS
Unless C: is not the drive that windows booted from.Parse the %SystemRoot% variable, it contains the location of the windows folder (i.e. c:\windows).
You can use WMI to figure this out. The Win32_BootConfiguration class will tell you both the logical drive and the physical device from which Windows boots. Specifically, the Caption property will tell you which device you're booting from.
For example, in powershell, just type gwmi Win32_BootConfiguration to get your answer.
That depends on your definition of which disk drive Windows used to boot. I can think of 3 different answers on a standard BIOS system (who knows what an EFI system does):
The drive that contains the active MBR
The active partition, with NTLDR (the system partition)
The partition with Windows on it (the boot partition)
2 and 3 should be easy to find - I'm not so sure about 1. Though you can raw disk read to find an MBR, that doesn't mean it's the BIOS boot device this time or even next time (you could have multiple disks with MBRs).
You really can't even be sure that the PC was started from a hard drive - it's perfectly possible to boot Windows from a floppy. In that case, both 1 and 2 would technically be a floppy disk, though 3 would remain C:\Windows.
You might need to be a bit more specific in your requirements or goals.
You type diskpart, list disk and check disks for boot.
Ex:
dispart
list disk
select disk 0
detail disk
The disk with Boot volume is disk with windows installed:
There is no boot.ini on a machine with just Vista installed.
How do you want to identify the drive/partition: by the windows drive letter it is mapped to (eg. c:\, d:) or by how its hardware signature (which bus, etc).
For the simple case check out GetSystemDirectory
Try HKEY_LOCAL_MACHINE\SYSTEM\Setup\SystemPartition
You can try use simple command line. bcdedit is what you need, just run cmd as administrator and type bcdedit or bcdedit \v, this doesn't work on XP, but hope it is not an issue.
Anyway for XP you can take a look into boot.ini file.
a simpler way
search downloads in the start menu and click on downloads in the search results to see where it will take you the drive will be highlighted in the explorer.
On Windows 10.
Open "Computer Management"
Look for "Storage" in list "left top side of page"
select "Disk Management"
On section of page showing the list of disks and the partitions find the disk that has the partition assigned as drive C:
On that disk containing C: partition
Use the right mouse button to select the Square section containing The Disk Number, Type of drive and size in GB . When menu opens select the Properties.
A window will open showing what drive hardware was used.