- Forum
- Windows Programming
- How to write file to usb drive
How to write file to usb drive
How to write c++ program
To transfer file to usb drive?
I did research on internet, couldn't
Find straight answer.
To transfer file to usb drive?
I did research on internet, couldn't
Find straight answer.
Since a USB drive usually mounts as a filesystem, the task is just writing files to a disk.
Just target the appropriate drive letter
Just target the appropriate drive letter
Last edited on
assuming windows?
somewhere in microsoft's os level stuff should be able to get a list of drives and info including its letter. find the usb drive and its letter.. from that...
or you can have the user pick the target: the standard file save dialog box lets you target it
if you are just playing locally, the drive letter probably wont change, for a 'personal use' program, in which case you can do it directly ( file.open("x:/filename") where x: is your drive letter on your machine.
basically, there isn't an easy way to know what it is on every computer that you use. If the user is not picking the drive for you, and you want full automation, you need to work at it by getting the drive letters and making it happen.
consider this cheesy solution: (I had to look this up, its above my memorized command level).
system("wmic logicaldisk where drivetype=2 get deviceid /format:value");
parse the output of that, may have to dump it to a file, and you are in businesss.
when I run that, I get this:
DeviceID=E:
so I now know I can target e:\filename
any command with > filename
will write the output text to that filename instead of the console.
unix will do it differently. Unix also has a way to get it from system commands, though -- but it could be mounted with a name spliced into your machine's path as a mount point or something. Windows, by the way, can also mount a drive as a folder, and it doesn't get a letter if you do that, but 99.999999 % of people don't even know you can do that, let alone bother with it. Im going to assume if you bother to use unix you can figure this out. ?
generally, using c++ as a 'enhanced batch file' and calling system commands this way is not really a good answer. It works for personal programs, quick fixes, and schoolwork. If you are doing anything professional/serious, you need to ask the OS about the filesystem via a library.
somewhere in microsoft's os level stuff should be able to get a list of drives and info including its letter. find the usb drive and its letter.. from that...
or you can have the user pick the target: the standard file save dialog box lets you target it
if you are just playing locally, the drive letter probably wont change, for a 'personal use' program, in which case you can do it directly ( file.open("x:/filename") where x: is your drive letter on your machine.
basically, there isn't an easy way to know what it is on every computer that you use. If the user is not picking the drive for you, and you want full automation, you need to work at it by getting the drive letters and making it happen.
consider this cheesy solution: (I had to look this up, its above my memorized command level).
system("wmic logicaldisk where drivetype=2 get deviceid /format:value");
parse the output of that, may have to dump it to a file, and you are in businesss.
when I run that, I get this:
DeviceID=E:
so I now know I can target e:\filename
any command with > filename
will write the output text to that filename instead of the console.
unix will do it differently. Unix also has a way to get it from system commands, though -- but it could be mounted with a name spliced into your machine's path as a mount point or something. Windows, by the way, can also mount a drive as a folder, and it doesn't get a letter if you do that, but 99.999999 % of people don't even know you can do that, let alone bother with it. Im going to assume if you bother to use unix you can figure this out. ?
generally, using c++ as a 'enhanced batch file' and calling system commands this way is not really a good answer. It works for personal programs, quick fixes, and schoolwork. If you are doing anything professional/serious, you need to ask the OS about the filesystem via a library.
Last edited on
Can you just tell us what you are doing in full instead of making a bunch of different threads?
one big fallacy that alot of beginners fall for is that they think they know what they need to solve their problem, but in reality if they gave more info in their question people will give them an easier practical solution. Or maybe what you are trying to do is impossible (as in not worth it for the effort).
one big fallacy that alot of beginners fall for is that they think they know what they need to solve their problem, but in reality if they gave more info in their question people will give them an easier practical solution. Or maybe what you are trying to do is impossible (as in not worth it for the effort).
for sure. devices like spyphones or cameras are not usb drives, they are usb devices that have a drive on them, and accessing the drive part is not always the same as just a usb stick.
Last edited on
@Monkey1999, "just trying to learn usb programming."
The notion of learning USB programming is most commonly in the domain of writing device drivers.
Let's say you have an Arduino or some other embedded controller. There will be a USB device driver added to the system you're using to connect to it. From there forward, what you would use is the application level library provided by the manufacturer for connecting to and controlling their device. You will not be involved with the operating system's USB interface doing that. You'll be using the manufacturer's representation of that as a device (not USB) now attached to the system.
If you have a flash drive, that already has a built in driver (though in rare cases one might be on the drive itself that is loaded), and that presents the device as a disk drive accessed through drive letter (which could be addressed as simply as using that letter in the filepath).
If it is a camera, again, there will be a device driver. It may provide a mounted device representing the camera, or it might make the camera appear like a disk drive.
Unless you're writing the device driver, and therefore are involved with the manufacturer of the device with a USB attachment, you're not going to be "programming the USB".
Though you can do so, every device you connect to the USB port uses it's own means of connecting, so again, you're referencing that specific device once you "open" the USB port. The USB is mainly about making a connection, sending and receive data, inquiring about status, etc.
To that extent it works much like the ancient and almost unused RS-232 serial port.
The notion of learning USB programming is most commonly in the domain of writing device drivers.
Let's say you have an Arduino or some other embedded controller. There will be a USB device driver added to the system you're using to connect to it. From there forward, what you would use is the application level library provided by the manufacturer for connecting to and controlling their device. You will not be involved with the operating system's USB interface doing that. You'll be using the manufacturer's representation of that as a device (not USB) now attached to the system.
If you have a flash drive, that already has a built in driver (though in rare cases one might be on the drive itself that is loaded), and that presents the device as a disk drive accessed through drive letter (which could be addressed as simply as using that letter in the filepath).
If it is a camera, again, there will be a device driver. It may provide a mounted device representing the camera, or it might make the camera appear like a disk drive.
Unless you're writing the device driver, and therefore are involved with the manufacturer of the device with a USB attachment, you're not going to be "programming the USB".
Though you can do so, every device you connect to the USB port uses it's own means of connecting, so again, you're referencing that specific device once you "open" the USB port. The USB is mainly about making a connection, sending and receive data, inquiring about status, etc.
To that extent it works much like the ancient and almost unused RS-232 serial port.
there are kind of 2 answers to 'usb programming'.
as us old people know, the USB is what used to be the 'serial port' on your computer. And there were a bunch of things you can plug into that... mouse, keyboard, gps, robotic arm, null modem cable, and so on. You had to know what it was to interface to it correctly. I mean, you can write a dumb program that opens the port and throws bytes at it and reads it if anything is there to be seen, but this is like opening a file on the hard drive at random ... good luck getting the right info from it or making any sense of it! So level 1 is just talking to the port, the mechanics of that, and part 2 is interfacing to what is plugged into it.
USB is similar. You have the mechanics of opening the port and sending and getting bytes from it, which is not difficult but takes a bit of code to set up and more if you wrap it in a class or use someone else's solution (have to learn that). And there is the device you want to talk to... and how to send commands and how to understand what it says back to you. This is specific to the device, or in the case of usb disks and other common devices, the class of device.
I would start with the how to open the port and talk to it. You can get a usb to rs232 adaptor and you can use a paperclip or whatever wire to make it talk to itself, so that that you transmit is what you get back. Then write a little program that can write to it and read from it, just a dumb echo. Start there. (I don't know a way to do this trick on USB. Is there a way?). Once you can do this, you can start looking at what you need to do to talk to something real.
as us old people know, the USB is what used to be the 'serial port' on your computer. And there were a bunch of things you can plug into that... mouse, keyboard, gps, robotic arm, null modem cable, and so on. You had to know what it was to interface to it correctly. I mean, you can write a dumb program that opens the port and throws bytes at it and reads it if anything is there to be seen, but this is like opening a file on the hard drive at random ... good luck getting the right info from it or making any sense of it! So level 1 is just talking to the port, the mechanics of that, and part 2 is interfacing to what is plugged into it.
USB is similar. You have the mechanics of opening the port and sending and getting bytes from it, which is not difficult but takes a bit of code to set up and more if you wrap it in a class or use someone else's solution (have to learn that). And there is the device you want to talk to... and how to send commands and how to understand what it says back to you. This is specific to the device, or in the case of usb disks and other common devices, the class of device.
I would start with the how to open the port and talk to it. You can get a usb to rs232 adaptor and you can use a paperclip or whatever wire to make it talk to itself, so that that you transmit is what you get back. Then write a little program that can write to it and read from it, just a dumb echo. Start there. (I don't know a way to do this trick on USB. Is there a way?). Once you can do this, you can start looking at what you need to do to talk to something real.
Last edited on
Topic archived. No new replies allowed.