Advantages - does not require writeblocker, fast, able to be used on multiple computers at one time, able to span the image file on an adhoc basis over multiple devices, ironclad image file, great log of what occurred during boot, device detection and imaging. ILOOKix works best and fastest when using it's own image files but can use other image files.
Disadvantages - proprietary image file - but capable of being converted to a dd or a vmdk from within ILOOKix.
Definitely it is me. (
I would call that list "features" and not "advantages" (to me an advantage is relative to something that is compared).
As a numbered list
Advantages
- does not require writeblocker
- fast
- able to be used on multiple computers at one time
- able to span the image file on an adhoc basis over multiple devices
- ironclad image file
- great log of what occurred during boot
- device detection and imaging.
- ILOOKix works best and fastest when using it's own image files but can use other image files.
From what I gathered till now
- does not require writeblocker (but qualified, long time users of it reported how they prefer to use a writeblocker anyway and there are other Linux or windows based Read Only solutions)
- fast (if used without a writeblocker)
- able to be used on multiple computers at one time (like any Linux based OS/tool)
- able to span the image file on an adhoc basis over multiple devices (like most other Linux based OS/tools)
- ironclad image file
- great log of what occurred during boot (like most other Linux based OS/tools)
- device detection and imaging. (like most other Linux or non-Linux based OS/tools)
- ILOOKix works best and fastest when using it's own image files but can use other image files.
[/listo]
So as I see it the main "leverage point" is the format of the image that is "ironclad" and that makes the processing with IlookIX faster (I cannot see how it can help making it "better") which in your view represents also a disadvantage.
I would personally see this aspect as very marginal and not a disadvantage since an image can be - if needed - converted back and forth, at the most it will take some time and some disk space, but nothing of actual relevance IMHO.
jaclaz
From what I gathered till now
- does not require writeblocker (but qualified, long time users of it reported how they prefer to use a writeblocker anyway and there are other Linux or windows based Read Only solutions)
- fast (if used without a writeblocker)
- able to be used on multiple computers at one time (like any Linux based OS/tool)
- able to span the image file on an adhoc basis over multiple devices (like most other Linux based OS/tools)
- ironclad image file
- great log of what occurred during boot (like most other Linux based OS/tools)
- device detection and imaging. (like most other Linux or non-Linux based OS/tools)
- ILOOKix works best and fastest when using it's own image files but can use other image files.
[/listo]
So as I see it the main "leverage point" is the format of the image that is "ironclad" and that makes the processing with IlookIX faster (I cannot see how it can help making it "better") which in your view represents also a disadvantage.
I would personally see this aspect as very marginal and not a disadvantage since an image can be - if needed - converted back and forth, at the most it will take some time and some disk space, but nothing of actual relevance IMHO.jaclaz
OK, features rather than advantages.
1. One longtime user reported using a write blocker with IXImager. The way a user chooses to use a tool cannot take away from the tool itself.
2. I believe that IX3 is still faster with a write blocker than other Linux distros without.
4. Able to span image file over multiple devices on an adhoc basis. I don't believe any other Linux distro will do this. Possibly if the image chunks are designated when the imaging is started but I'm not at all sure they would do so even then. If you know of one that does, the name would be useful so I can check it out.
Debbie
1. One longtime user reported using a write blocker with IXImager. The way a user chooses to use a tool cannot take away from the tool itself.
Sure it does not ) , as said before this point is not "IXimager specific" but "generic procedure".
There are other tools beside IXimager that are considered to be "read only" and thus can be used in theory without write blocker.
IXimager has the advantage over other tools of having been tested (in the previous 2.0 version) by NIST and found to be compliant in all respects.
Since the tests were performed in 2006 I would have thought that in the following years IXimager users (or at least most of them) would have by now tested themselves extensively the read-only capabilities, verified them and consequently abandoned the usage of a writeblocker in conjunction with it.
If you prefer this theoretical advantage is nullified in practice by common use of the tool in a way which is more cautious than what would be needed.
2. I believe that IX3 is still faster with a write blocker than other Linux distros without.
Yes, this is very possible (within limits, bus, actual disk controller, etc.) as the tool may have been finely tuned for data transfer, but one would need to do some comparative tests to be sure.
4. Able to span image file over multiple devices on an adhoc basis. I don't believe any other Linux distro will do this. Possibly if the image chunks are designated when the imaging is started but I'm not at all sure they would do so even then. If you know of one that does, the name would be useful so I can check it out.
Maybe I misunderstood the "ad hoc". ?
I was talking of taking "partial" images (or if you prefer image in "chunks") and have the partial images saved to different media, this is of course possible using dd or any of it's derivatives.
Can you better describe this "ad hoc" capabilities?
Do you provide to the tool a "pool" of destination disks and then the tool automatically determines how to use them (like filling first one "up to the brim", then start writing to second disk, etc.?
jaclaz
4. Able to span image file over multiple devices on an adhoc basis. I don't believe any other Linux distro will do this. Possibly if the image chunks are designated when the imaging is started but I'm not at all sure they would do so even then. If you know of one that does, the name would be useful so I can check it out.
Maybe I misunderstood the "ad hoc". ?
I was talking of taking "partial" images (or if you prefer image in "chunks") and have the partial images saved to different media, this is of course possible using dd or any of it's derivatives.
Can you better describe this "ad hoc" capabilities?
Do you provide to the tool a "pool" of destination disks and then the tool automatically determines how to use them (like filling first one "up to the brim", then start writing to second disk, etc.?jaclaz
When imaging with IX3, if the destination disk becomes full, one is prompted to insert the next destination disk. No need to specify chunk sizes, although chunks are automatically created at the same size as the first so the first should be the largest disk size if you think this might happen.
When imaging with IX3, if the destination disk becomes full, one is prompted to insert the next destination disk. No need to specify chunk sizes, although chunks are automatically created at the same size as the first so the first should be the largest disk size if you think this might happen.
I am not sure to understand.
Let's say you have to image a 1 Tb disk.
Normally you would have available a 1 or 1.5 Tb disk and have no issues whatsoever in creating the image in one chunk or have all the chunks on the same disk.
By mistake in your bag four smallish disks remain
- 3 x 320 Gb disks
- 1 x 250 Gb disks
If using manually *any* "plain" dd (using not any form of compression - think of emergency backup/data recovery instead of forensic work) I would make a 200 Gb chunk and save it on the 250 Gb disk two more chunks about 300 Gb and save them on two of the three 320 GB disks and a "final chunk" with the rest and save it to the third 320 Gb disk.
If using a compressed format I would probably estimate a 40% reduction and try using two 320 Gb disks to hold respectively first 500 Gb and second 500 Gb, making chunks about 50 Gb each (on source).
I know that many tools use a fixed smallish size for chunks, like 640 Mb or 1 Gb or 4 gb or the like.
How would you deal with the situation with IX imager?
I mean would you start as your first disk with one of the 320 Gb ones or with the 250 Gb one?
Or is it irrelevant?
The "auto-prompt for new media" when the disk is nearly full seems to me a very nice feature, but I think it is "standard" for a Commercial program, FTK imager, if I recall correctly, offers the same feature.
But then I think you have to re-compose all the chunks into a single path to access them, maybe IlookIX allows to make a "fusion-FS" like filesystem in this case?
Another question, does IXimager allow imaging more devices at the same time (like for example guymager allows)?
jaclaz
I know that many tools use a fixed smallish size for chunks, like 640 Mb or 1 Gb or 4 gb or the like.
How would you deal with the situation with IX imager?
I mean would you start as your first disk with one of the 320 Gb ones or with the 250 Gb one?
Or is it irrelevant?The "auto-prompt for new media" when the disk is nearly full seems to me a very nice feature, but I think it is "standard" for a Commercial program, FTK imager, if I recall correctly, offers the same feature.
But then I think you have to re-compose all the chunks into a single path to access them, maybe IlookIX allows to make a "fusion-FS" like filesystem in this case?Another question, does IXimager allow imaging more devices at the same time (like for example guymager allows)?
jaclaz
IX3 can use a smaller sized image segment size, if desired. I personally use the single segment size myself.
If I were imaging, I would tell IX3 I wanted a single segment and use the 320 GB first. If it ran out of room, it would ask for more media and I would detach the 320 and attach the 250. The image would now be segmented. -(
I don't think the auto-prompt for new media is standard in FTKImager and other tools but I use them rarely and could be wrong.
With ILook, you must have all image segments on one hard drive to load them into the case. If I ended up with segmented images on separate media I would either convert the image to a single image using IX3 itself or I would copy the two segments to a RAID or a larger hard drive.
Although IX3 is capable of making more than one image at once, that feature is not implemented.
Well this storm in a teacup isn't getting boring at all is it? No siree!
Hmmm, someone is asking questions and others are answering them . . . .
The content is reflected pretty clearly in the subject line. If you're not interested, don't click on it.
Although IX3 is capable of making more than one image at once, that feature is not implemented.
Well, with all due respect ) , this sounds again like one of the "foggy" statements I am trying to disambiguate/clear.
It is pretty much binary to me, either it does or it does not.
I understand that it does not.
(whether this happens because it is capable but not implemented or because it is not capable and not implemented does not make any difference in practice)
We will need some input from members familiar with other Commercials tools to understand if the "ad hoc" feature is not present in other tools/suites.
From what I remember the FTK imager works because you first tell it to make a number of "small sized chunks", say 1.5 Gb in size, then it starts making n files 1.5 Gb in size and before making each checks the available space remaining on the "target" and if it not enough for the mth file, then prompts for new media.
If you prefer the check for available space is done "between" separate "dd-like commands", while from what I understand from your post IXimager does it "while" executing a single, initial "dd-like" command.
The feature you described in IX imager seems much nicer to me.
jaclaz