Helping people with computers... one answer at a time.
It is unlikely that manufactures of devices like cameras and GPS navigators would allow users the kind of access needed to restore an ISO file. But, there is a way to test that flash drive question.
I have XP Pro SP3. I just used ImgBurn (create image file from files/folders) to make an ISO file from my Garmin Nuvi 765T (which showed up as my drive H:\.) Did it make an "image" of the GPS (by this, I mean everything including "hidden" files)? Or, did it take all the files/folder and then create a file from them? All of the definitions of ISO that I read imply that it takes all the sectors and creates the image, which would imply that one could use that image to do a "restore" if the GPS became damaged. Would that be correct? Same could be asked for a flash drive, I suspect.
•
In this excerpt from Answercast #20, I look at the way ISO files work and offer a simple test to see what is being retrieved from a USB flash drive.
•
The flash drive scenario is easier because Windows has more direct access to the flash drive than it probably does for the GPS.
I believe that an ISO could certainly be laid back out to a flash drive just as easily as you could create an ISO from it.
(Note: A Garmin is a Bluetooth portable GPS Navigator)
For a device like a Garmin or a camera or an MP3 player or what not, I honestly don't know if you can just lay an ISO back out onto what appears as flash memory when that device is connected. The issue is that a flash drive, a plain old thumb drive really, is just a virtual disk drive.
When you plug in a device like a phone or a Garmin (or anything that is more than just some memory on a stick), they are emulating a disk drive. In other words, they are basically emulating or providing just enough functionality so that you can actually read and write files to and from the device.
I'm actually kinda surprised that you can make an ISO from it, but the fact that is that you could.
Whether you could write the ISO back out, I have absolutely no idea. It really depends on the level of functionality that the Garmin people decided to include in their USB connection interface.
Now to be honest, if I were them, I would absolutely prevent what you are attempting to do. To me as a manufacturer, I would assume that it would allow people too much (I hate to say) control; but basically, it would give them much more access than most people need. It would potentially open doors to customer support problems, when they accidentally render their device inoperable because of a failed ISO write.
So, I would not expect it to work.
To answer the first question that you asked, "Does it take all of the files and folders and create a file from them including hidden files?" My understanding (I could be wrong), but my understanding that an ISO file is technically not necessarily a sector by sector copy. I think it can be, but by-and-large, it's more like a file copy.
Now, having said that, does it include hidden files? Well, hidden files are files. Windows has a concept of a hidden file, but that file's still there.
Is it going to include all of the empty space in a drive? Don't think so. In other words, is it actually going to copy all of the sectors that aren't currently in use? I believe the answer to that is no.
If you want to find out, that's easily testable.
Go grab a flash drive. Put a couple of files on it and keep track of how big the flash drive is compared to how big the data you've placed on the hard drive is. Create an ISO file from the flash drive. If the ISO is more or less the same size as the data that you put on the flash drive, then you know that it doesn't include the empty space.
If, on the other hand, the ISO is more or less the same size as the entire
flash drive (in other words, the whole capacity of the flash drive), then you
know that the ISO software you're using is creating an actual sector-by-sector
copy of the flash drive, or whatever else it is you are creating ISO files
from.
Next from Answercast 20 - How can I download Internet Explorer?
Article C5383 - May 24, 2012 « »