Copying ISO contents and ISO vs ZIP
I understand why an .iso file cannot simply be copied to a given storage device (USB stick, another hard drive etc) and then "just work". I'm wondering if the same holds true for "burned/extracted" results? And why not downloadable zip files instead of iso in the first place?
By way of a concrete example:
I wanted a disk wiping tool, and decided to use DBAN. The download was an iso file, which I burned to a USB stick, using Rufus. Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Another silly question: Why bother with iso files at all? Why not provide zip files to download instaed? I'm going to take a guess and maybe I'm answering my own question here: Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
iso-image
add a comment |
I understand why an .iso file cannot simply be copied to a given storage device (USB stick, another hard drive etc) and then "just work". I'm wondering if the same holds true for "burned/extracted" results? And why not downloadable zip files instead of iso in the first place?
By way of a concrete example:
I wanted a disk wiping tool, and decided to use DBAN. The download was an iso file, which I burned to a USB stick, using Rufus. Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Another silly question: Why bother with iso files at all? Why not provide zip files to download instaed? I'm going to take a guess and maybe I'm answering my own question here: Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
iso-image
add a comment |
I understand why an .iso file cannot simply be copied to a given storage device (USB stick, another hard drive etc) and then "just work". I'm wondering if the same holds true for "burned/extracted" results? And why not downloadable zip files instead of iso in the first place?
By way of a concrete example:
I wanted a disk wiping tool, and decided to use DBAN. The download was an iso file, which I burned to a USB stick, using Rufus. Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Another silly question: Why bother with iso files at all? Why not provide zip files to download instaed? I'm going to take a guess and maybe I'm answering my own question here: Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
iso-image
I understand why an .iso file cannot simply be copied to a given storage device (USB stick, another hard drive etc) and then "just work". I'm wondering if the same holds true for "burned/extracted" results? And why not downloadable zip files instead of iso in the first place?
By way of a concrete example:
I wanted a disk wiping tool, and decided to use DBAN. The download was an iso file, which I burned to a USB stick, using Rufus. Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Another silly question: Why bother with iso files at all? Why not provide zip files to download instaed? I'm going to take a guess and maybe I'm answering my own question here: Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
iso-image
iso-image
asked Jan 21 at 18:44
clgclg
72
72
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
I guess you're referring to this earlier thread.
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Still no, for the exact same reason: you won't be copy/pasting the entire contents, you will be copy/pasting only the part that's shown as "files and folders". But just like the .iso image had invisible data beyond that, the final USB stick also has data beyond that – such as the MBR bootcode, the partition layout, the particular choice of filesystems used – which a simple copy/paste will not pick up.
For example, PC BIOS systems require the disk's 0th sector to contain "boot code" – the first-stage bootloader. This is not stored as a file (because BIOS does not understand files), therefore it won't be copied if you only copy files.
UEFI systems do store the bootloader as a file, but they generally want it to be on a FAT16/FAT32 filesystem. If you copy & paste the files into an NTFS device, most UEFI systems won't be able to access them.
Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
I think one clarification is necessary: The file system is not a special parameter that the "formatting" or "burning" process has to modify in a special way. In reality, filesystem structures are stored on the disk in exactly the same way as regular data. The same goes for the partition table; it's just some data on a sector.
Therefore a sector-by-sector copy of a whole disk will automatically include the entire filesystem – it'll include the fact that it's e.g. a FAT32 filesystem; it'll include every single bit of the filesystem's internal structure/metadata/attributes; it'll reproduce even the partition layout.
So it isn't merely that an .iso disk image is "filesystem-agnostic"; rather, it brings its own filesystem as part of the image. (Indeed this is where the "iso" name comes from: originally .iso files meant images of a CD containing the ISO 9660 filesystem.)
add a comment |
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
No; You would only be copying the contents of the bootable partition that exists on the bootable drive. You need to duplicate the partition in order to make the contents of the disk bootable.
Why bother with iso files at all?
ISO 9660 is a standard to distribute images of optical media. It literally exists for the exact purpose of distributing images of bootable media.
ISO 9660 is a file system for optical disc media. Being published by the International Organization for Standardization (ISO) the file system is considered an international technical standard. Since the specification is available for anybody to purchase,1 implementations have been written for many operating systems.
Source: ISO 9660
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1396733%2fcopying-iso-contents-and-iso-vs-zip%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I guess you're referring to this earlier thread.
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Still no, for the exact same reason: you won't be copy/pasting the entire contents, you will be copy/pasting only the part that's shown as "files and folders". But just like the .iso image had invisible data beyond that, the final USB stick also has data beyond that – such as the MBR bootcode, the partition layout, the particular choice of filesystems used – which a simple copy/paste will not pick up.
For example, PC BIOS systems require the disk's 0th sector to contain "boot code" – the first-stage bootloader. This is not stored as a file (because BIOS does not understand files), therefore it won't be copied if you only copy files.
UEFI systems do store the bootloader as a file, but they generally want it to be on a FAT16/FAT32 filesystem. If you copy & paste the files into an NTFS device, most UEFI systems won't be able to access them.
Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
I think one clarification is necessary: The file system is not a special parameter that the "formatting" or "burning" process has to modify in a special way. In reality, filesystem structures are stored on the disk in exactly the same way as regular data. The same goes for the partition table; it's just some data on a sector.
Therefore a sector-by-sector copy of a whole disk will automatically include the entire filesystem – it'll include the fact that it's e.g. a FAT32 filesystem; it'll include every single bit of the filesystem's internal structure/metadata/attributes; it'll reproduce even the partition layout.
So it isn't merely that an .iso disk image is "filesystem-agnostic"; rather, it brings its own filesystem as part of the image. (Indeed this is where the "iso" name comes from: originally .iso files meant images of a CD containing the ISO 9660 filesystem.)
add a comment |
I guess you're referring to this earlier thread.
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Still no, for the exact same reason: you won't be copy/pasting the entire contents, you will be copy/pasting only the part that's shown as "files and folders". But just like the .iso image had invisible data beyond that, the final USB stick also has data beyond that – such as the MBR bootcode, the partition layout, the particular choice of filesystems used – which a simple copy/paste will not pick up.
For example, PC BIOS systems require the disk's 0th sector to contain "boot code" – the first-stage bootloader. This is not stored as a file (because BIOS does not understand files), therefore it won't be copied if you only copy files.
UEFI systems do store the bootloader as a file, but they generally want it to be on a FAT16/FAT32 filesystem. If you copy & paste the files into an NTFS device, most UEFI systems won't be able to access them.
Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
I think one clarification is necessary: The file system is not a special parameter that the "formatting" or "burning" process has to modify in a special way. In reality, filesystem structures are stored on the disk in exactly the same way as regular data. The same goes for the partition table; it's just some data on a sector.
Therefore a sector-by-sector copy of a whole disk will automatically include the entire filesystem – it'll include the fact that it's e.g. a FAT32 filesystem; it'll include every single bit of the filesystem's internal structure/metadata/attributes; it'll reproduce even the partition layout.
So it isn't merely that an .iso disk image is "filesystem-agnostic"; rather, it brings its own filesystem as part of the image. (Indeed this is where the "iso" name comes from: originally .iso files meant images of a CD containing the ISO 9660 filesystem.)
add a comment |
I guess you're referring to this earlier thread.
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Still no, for the exact same reason: you won't be copy/pasting the entire contents, you will be copy/pasting only the part that's shown as "files and folders". But just like the .iso image had invisible data beyond that, the final USB stick also has data beyond that – such as the MBR bootcode, the partition layout, the particular choice of filesystems used – which a simple copy/paste will not pick up.
For example, PC BIOS systems require the disk's 0th sector to contain "boot code" – the first-stage bootloader. This is not stored as a file (because BIOS does not understand files), therefore it won't be copied if you only copy files.
UEFI systems do store the bootloader as a file, but they generally want it to be on a FAT16/FAT32 filesystem. If you copy & paste the files into an NTFS device, most UEFI systems won't be able to access them.
Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
I think one clarification is necessary: The file system is not a special parameter that the "formatting" or "burning" process has to modify in a special way. In reality, filesystem structures are stored on the disk in exactly the same way as regular data. The same goes for the partition table; it's just some data on a sector.
Therefore a sector-by-sector copy of a whole disk will automatically include the entire filesystem – it'll include the fact that it's e.g. a FAT32 filesystem; it'll include every single bit of the filesystem's internal structure/metadata/attributes; it'll reproduce even the partition layout.
So it isn't merely that an .iso disk image is "filesystem-agnostic"; rather, it brings its own filesystem as part of the image. (Indeed this is where the "iso" name comes from: originally .iso files meant images of a CD containing the ISO 9660 filesystem.)
I guess you're referring to this earlier thread.
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
Still no, for the exact same reason: you won't be copy/pasting the entire contents, you will be copy/pasting only the part that's shown as "files and folders". But just like the .iso image had invisible data beyond that, the final USB stick also has data beyond that – such as the MBR bootcode, the partition layout, the particular choice of filesystems used – which a simple copy/paste will not pick up.
For example, PC BIOS systems require the disk's 0th sector to contain "boot code" – the first-stage bootloader. This is not stored as a file (because BIOS does not understand files), therefore it won't be copied if you only copy files.
UEFI systems do store the bootloader as a file, but they generally want it to be on a FAT16/FAT32 filesystem. If you copy & paste the files into an NTFS device, most UEFI systems won't be able to access them.
Because an iso is a sector-by-sector container copy of a physical storage medium like a DVD or CD. As such, the container is operating-system agnostic. And maybe also file system agnostic (so It's doesn't matter if the files system is, for example, NTFS or APFS)?
I think one clarification is necessary: The file system is not a special parameter that the "formatting" or "burning" process has to modify in a special way. In reality, filesystem structures are stored on the disk in exactly the same way as regular data. The same goes for the partition table; it's just some data on a sector.
Therefore a sector-by-sector copy of a whole disk will automatically include the entire filesystem – it'll include the fact that it's e.g. a FAT32 filesystem; it'll include every single bit of the filesystem's internal structure/metadata/attributes; it'll reproduce even the partition layout.
So it isn't merely that an .iso disk image is "filesystem-agnostic"; rather, it brings its own filesystem as part of the image. (Indeed this is where the "iso" name comes from: originally .iso files meant images of a CD containing the ISO 9660 filesystem.)
edited Jan 21 at 19:21
answered Jan 21 at 19:00
grawitygrawity
239k37508561
239k37508561
add a comment |
add a comment |
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
No; You would only be copying the contents of the bootable partition that exists on the bootable drive. You need to duplicate the partition in order to make the contents of the disk bootable.
Why bother with iso files at all?
ISO 9660 is a standard to distribute images of optical media. It literally exists for the exact purpose of distributing images of bootable media.
ISO 9660 is a file system for optical disc media. Being published by the International Organization for Standardization (ISO) the file system is considered an international technical standard. Since the specification is available for anybody to purchase,1 implementations have been written for many operating systems.
Source: ISO 9660
add a comment |
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
No; You would only be copying the contents of the bootable partition that exists on the bootable drive. You need to duplicate the partition in order to make the contents of the disk bootable.
Why bother with iso files at all?
ISO 9660 is a standard to distribute images of optical media. It literally exists for the exact purpose of distributing images of bootable media.
ISO 9660 is a file system for optical disc media. Being published by the International Organization for Standardization (ISO) the file system is considered an international technical standard. Since the specification is available for anybody to purchase,1 implementations have been written for many operating systems.
Source: ISO 9660
add a comment |
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
No; You would only be copying the contents of the bootable partition that exists on the bootable drive. You need to duplicate the partition in order to make the contents of the disk bootable.
Why bother with iso files at all?
ISO 9660 is a standard to distribute images of optical media. It literally exists for the exact purpose of distributing images of bootable media.
ISO 9660 is a file system for optical disc media. Being published by the International Organization for Standardization (ISO) the file system is considered an international technical standard. Since the specification is available for anybody to purchase,1 implementations have been written for many operating systems.
Source: ISO 9660
Can I now copy/paste the entire contents of that stick to another stick and expect it to work?
No; You would only be copying the contents of the bootable partition that exists on the bootable drive. You need to duplicate the partition in order to make the contents of the disk bootable.
Why bother with iso files at all?
ISO 9660 is a standard to distribute images of optical media. It literally exists for the exact purpose of distributing images of bootable media.
ISO 9660 is a file system for optical disc media. Being published by the International Organization for Standardization (ISO) the file system is considered an international technical standard. Since the specification is available for anybody to purchase,1 implementations have been written for many operating systems.
Source: ISO 9660
edited Jan 21 at 19:23
answered Jan 21 at 18:57
RamhoundRamhound
20.6k156286
20.6k156286
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1396733%2fcopying-iso-contents-and-iso-vs-zip%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown