Jump to content











Photo
- - - - -

Mounting split image


  • Please log in to reply
42 replies to this topic

#1 ilko

ilko

    Silver Member

  • Advanced user
  • 500 posts
  •  
    Bulgaria

Posted 19 April 2015 - 09:57 PM

I need to mount split image, preferably ISO file. Might put them in another container if need to.

Does ImDisk support any kind of split into multiple files images?

Would ImDisk support mounting nested images, lets say ISO in a split VHD or whatever container, i.e. mount the VHD then mount the ISO inside it?

 

The goal is to overcome FAT32 4GB limit and mount larger ISO images, put in supported container if need to.

 



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 April 2015 - 09:06 AM

Only to clarify.

You are saying more or less that you want on a FAT32 filesytem two files that once sequentially (and virtually) re-joined are bigger than 4 Gb, right?

Example:

mynice.iso sized 5 Gb would become mynice_01.pmi sized slightly less than 4 Gb and mynice_02.pmi sized roughly 1 Gb (pmi=partial multi-file image) 

 

Then IMDISK (or something else) should virtually create a "whole" mynice.iso or however mount the two parts as a single drive letter...

 

Nice idea. :)

 

I would also think (though cannot say if possible with some trickery :unsure:) about some creative use of something *like*  a "fake" NTFS and junctions/links.

 

Maybe this is work for devio rather than imdisk itself. :dubbio:

 

:duff:

Wonko



#3 ilko

ilko

    Silver Member

  • Advanced user
  • 500 posts
  •  
    Bulgaria

Posted 25 April 2015 - 02:06 PM

Yep, that's the idea. Or if split ISO file is not possible, put it another, supported one, i.e. in vhd or whichever supported format which contains NTFS/exfat volume with the large ISO file in it, as long as imdisk can mount such nested structure- first mount the vhd or whatever container, then mount the ISO file in it.

#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 25 April 2015 - 06:17 PM

Good. :)

Temporarily (i.e. until Olof, v77 and/or erwan.l) take your idea into consideration, forget about it :w00t:, and do some tests with Arsenal Image Mounter using the EWF/E01 format.

The EWF format is designed to be multipart and Arsenal Image Mounter is compatible with it (and with the multi-part EWF sub-format):

http://reboot.pro/to...-disk-from-ewf/

 

Check (cannot say) if the same support has been added to IMDISK :unsure:, surely OFSMount (which essentially is basically an extended IMDISK) has it:

http://www.osforensi...isk-images.html

 

You can use Forensic Imager to create the .E01 test files:

http://www.forensicimager.com/

or FTK Imager:

http://accessdata.com/product-download

most probably there are other tools, but right now I cannot remember any other under Windows or if you are into Linux, guymager

http://sourceforge.n...jects/guymager/

or pretty much *anything* that uses LIBEWF

 

:duff:

Wonko 



#5 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 26 April 2015 - 03:51 PM

Note that ImDisk can also mount EWF file with a proxy here.

The proxy will support splitted EWF files.

 

Sidenote, with the ImDisk proxy feature, it should be pretty simple to implement splitted files (once the details are aggreed).

 

Side sidenote, CloneDisk can also backup/restore from/to E01 files.

Restore works with EWF splitted files.

 

More on the excellent libewf here.



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 26 April 2015 - 06:33 PM

Sidenote, with the ImDisk proxy feature, it should be pretty simple to implement splitted files (once the details are aggreed).

Good that you may be interested in this matter :).

Unless there is a valid reason to re-invent the wheel, I would suggest the existing (though lesser known/used) CISO format:

http://www.pismotechnic.com/ciso/

 

This set aside, if there was a way (probably there is one through devio, but I am not at all familiar with it's usage) to tell IMDISK to mount an area of a \\.\PhysicalDrive (i.e. from start sector to end sector) as a drive/volume the problem would be solved as long as the split image parts are:

  1. contiguous (in the sense that each of them is composed of a sequence of sectors)
  2. contiguous (in the sense that there is no gap between them)

 

Ideally (just wishful thinking :unsure:) if we could tell IMDISK to "assemble" multiple  range of sectors into a "volume object" it would be relatively easy to use a tool *like* getFileExtents.exe or myfragmenter.exe, some reference here:

http://www.msfn.org/...essful-unbrick/

to get the extents for each "split part" of the "normal" .iso split into two or more parts and feed it to imdisk. 

 

:duff:

Wonko



#7 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 26 April 2015 - 11:08 PM

This set aside, if there was a way (probably there is one through devio, but I am not at all familiar with it's usage) to tell IMDISK to mount an area of a \\.\PhysicalDrive (i.e. from start sector to end sector) as a drive/volume the problem would be solved as long as ...


This is rather easy nowadays with ImDisk. Simply specify a physical drive object as "image file" and specify offset and size as -b and -s switches. Example:

imdisk -a -f \\?\physicaldrive1 -b 200000 -s 300000 -m #:

 

-f \\?\physicaldrive1 - path to physical drive object

-b 200000 = offset in bytes

-s 300000 = size in bytes (length to use after offset)

 

For first experiments add -o ro for read-only operation, so that ImDisk does not overwrite anything until you know that it works and you have got the right offsets and lengths.

 

And yes, I use this method now and then to mount secondary partitions on USB thumb drives that are not directly visible in Windows. :)

 


  • imnothing likes this

#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 April 2015 - 09:52 AM

Very good :), I suspected that something like that was possible, but never dared to ask ;).

 

Now, you are surely accustomed to the users of IMDISK asking you crazy features, so I believe I can quickly throw this on the table and promptly hide my hand behind my back.

 

As I see it, the "right way" for this particular use needed by ilko would be to use a "split filesystem" format, such as the mentioned EWF/E01 or the proposed CISO format (or another simple format), but still this "direct mapping" approach would have it's merits, the difficulty may be to find a suitable tool to make sure that the image split parts are contiguous, so, if possible at all :dubbio: :unsure: having the possibility to map more non-contiguous extents would be perfect.

Something *like*:

imdisk -a -o ro -f \\?\physicaldrive1 -b0 200000 -s0 300000 -b1 400000 -s1 100000 -m #:

 

:duff:

Wonko



#9 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 27 April 2015 - 12:07 PM

Very good :), I suspected that something like that was possible, but never dared to ask ;).

 

Now, you are surely accustomed to the users of IMDISK asking you crazy features, so I believe I can quickly throw this on the table and promptly hide my hand behind my back.

 

As I see it, the "right way" for this particular use needed by ilko would be to use a "split filesystem" format, such as the mentioned EWF/E01 or the proposed CISO format (or another simple format), but still this "direct mapping" approach would have it's merits, the difficulty may be to find a suitable tool to make sure that the image split parts are contiguous, so, if possible at all :dubbio: :unsure: having the possibility to map more non-contiguous extents would be perfect.

Something *like*:

imdisk -a -o ro -f \\?\physicaldrive1 -b0 200000 -s0 300000 -b1 400000 -s1 100000 -m #:

 

:duff:

Wonko

 

I was planning on trying to implement some sort of split logic thru a devio proxy.

Something very simple like : if requested offset > current file length, then look for current file+.'001' (extension), etc ...

 

If really brave (which I am not :) ), I could even strictly follow the CISO specs... and come with a CISO Imdisk proxy, next to the other proxies I pushed over here (qcow, vhd, vmdk, ewf).



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 27 April 2015 - 02:08 PM

Actually I had hoped that you were brave enough :whistling: as that way we would have an alternative mounting tool and a practical command line or GUI tool to actually create/convert the CISO "split files" (of course there is no need to implement features such as compression, encryption, etc.), for NO apparent reason here is the ptiso convert help.txt :

 

syntax: ptiso convert [<switch> ...] <input file>|- <output file>|-
switches:
-i <input password> Password for decrypting input image.
-b <frame size> Encryption/compression/hash frame size.
-c <hash type> Generate tamper resistant image.
-e <encryption type> Encrypt output image.
-f Replace file if it already exists.
-g Use graphical user interface.
-m <max file size> Split image into parts.
-p <output password> Password for encrypting output image.
-q Do not display progress.
-s <sign command> Command to execute to sign image.
-t <output image format> Output image format.
-x <stub option> <value> Executable stub options.
-y <stub resource id> <file name> Embed file in executable stub resources.
-z <compression type> Compress output image.
output image formats:
ciso
iso
compression types:
none
lzma Large dictionary LZSS with adaptive range coding.
zip LZSS with Huffman coding.
hash types:
none
crc32 Simple CRC32 to detect file corruptions.
sha256 Strong hash for use with digital signatures.
encryption types:
none
aes128 XTS mode AES 128 bit encryption using PKCS5v2 password derived key.
stub options:
stub <file name> Executable stub for image.
icon <file name> Icon for executable stub.
iconid <id> Numeric ID of icon in icon file.
version <filename> File containing version resource for executable stub.
runas [user|admin] Manifest require user or administrator priviliges.
Remaining stub options are stored in executable stub resources for use at runtime. Options recognized by PFM stub (ptsmx.stub) include:
require_administrator [0|1] Fail if not run as administrator.
mount_system_visible [0|1] Mount system visible.
process_visible [0|1] Mount visible only to run executable.
run_exe <executable> Executable to run.
verify_media [0|1] Verify media at mount.
run_relative [0|1] Run executable is located in mount.
use_stderr [0|1] Write diagnostic messages to stderr.
notes:
If - is specified for input file then image data will be read from standard in. In this case the input image must be a simple 2048 byte sector dump (.ISO), such as output from mkisofs or dd.
If - is specified for output file then image data will be written to standard out. Some output image formats and options cannot be used when writing to standard out.
examples:
>ptiso convert -t ciso -z lzma someimage.iso someimage.ciso
>ptiso convert someimage.ciso - > someimage.iso
>mkisofs somefolder | ptiso convert -t ciso - someimage.ciso

 

and attached a screenshot of the GUI highlighting the "predefined" split sizes.

 

Of course a "much plainer" split set of files proxy would also do nicely :thumbsup:, still   :unsure:...

Spoiler

 

 

:duff:
Wonko

Attached Thumbnails

  • ptisoconvert.jpg


#11 ilko

ilko

    Silver Member

  • Advanced user
  • 500 posts
  •  
    Bulgaria

Posted 28 April 2015 - 07:27 AM

CISO format looks promising, spot on, thanks for the info Jaclaz.
Now if only imdisk supports it somehow...

#12 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 28 April 2015 - 07:33 AM

Just wanted to add one more option, Arsenal Image Mounter can also mount split raw images. The implementation is probably not very efficient though because it is implemented as a .NET 4.0 Stream with a shared memory proxy.

It also has a few restrictions, such as all parts need to be the same size (except for the last one). But I just wanted to mention this feature anyway. Just click the "Mount multi-part raw" button in the graphical Mount Tool.

#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 April 2015 - 09:55 AM

@Olof

Well, this thread was going on pretty fine until you named the four letter word :w00t: :ph34r: (actually three letter word with a dot at the beginning) :whistling:

 

@ilko

If none of the good guys that normally deal with IMDISK and it's extensions/evolution is interested in the matter, you could well use the Pismo mount tool instead of IMDISK, the basic way of working is not-so-different, like you know:
pfm mount -a -r -m W split.ciso

would nicely mount the files:

 

split.ciso
split.ciso.2_6
split.ciso.3_6
split.ciso.4_6
split.ciso.5_6
split.ciso.6_6

 

to W: drive letter

and 

pfm unmount split.ciso

will unmount it.

 

Though as said for your specific use it is maybe overkill.

The nice trick shared by Olof about mapping an extent on a \\.\Physicaldrive object could at the end of the day result being more suited.

The not-so-trifling advantage of using (I presume no more than two split parts) contiguously mapped files would be that even grub4dos could mount/access the large .iso using (say) a partnew command and a mapping in the MBR.

 

The issue may reside in the way the FAT32 filesystem is populated in order to have the two split parts contiguous, but I am pretty sure we could find a relatively simple way to create that, as long as the filesystem won't be later defragmented or modified. :) 

 

:duff:

Wonko



#14 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 28 April 2015 - 10:24 AM

2 remarks :

 

-there might be tools out there that can speficy to which offset you want to copy a (split) file ?

 

-may be deviating from the topic but a vmdk disk descriptor file (a simple text file actually) could also be used to point at all splitted files?

if so, imdisk + libvmdk proxy could be of some help?

exemple here.

 

EDIT : a nice tool over here (nfscopy) similar to getextents.

Not sure thus it can copy a file at a specific location like mentionned above.



#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 April 2015 - 12:35 PM

The .vmdk descriptor could be a nice approach :thumbsup:, I wonder if it would apply to a .iso file or if one would need a matrioschka approach using a NTFS volume as VMDK containing the .iso, the "right" format fo this would be the "twoGbMaxExtentFlat" or rather the "experimental"  that seems like an extension to the flat 2 Gb with arbitrary size.

Or maybe one could use a hybrid .iso, if this would be possible we would have a plain enough solution.

 

The ntfscopy is - well - ntfs. :(

 

AFAIK/AFAICR if you copy two files one after the other on a FAT volume (no matter if FAT12/16/32) to the same directory they will be contiguous (in themselves and "one after the other")  and a tool like the ones in the utilities here:

http://www.partition...m/utilities.htm

may verify this, the issue I see with this approach is in the case of a modification of the FAT32 filesystem for any reason.

 

:duff:

Wonko



#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 28 April 2015 - 06:32 PM

Ok, I think we have a winning (simple) idea. :yahoo:

The libvmdk approach suggested by erwan.l seems like working nicely :thumbup:, at least in "reduced scale" tests. 
 
I have no way right now to create and test such a large .iso file, not on this machine and not in my grand pa' windows :whistling: in order to test a batch file I am working on, but as soon as I have it theoretically working, I will post it.
 
In the meantime a few NOTES.
NOTES:
Maximum FAT32 filesize: 4294901760 bytes according to the Pismo screenshot posted earlier, 4294967295 theoretical, will need to be tested.

To workaround limitations in batch math, one can use Olof's nice rawcopy that though not really-really documented, allows for using suffixes K, M and G in size.
So, 4G would be too much and 4095M sounds like "just right" as 4095*1024*1024=4293918720
 
 
The command:
devio --dll=proxy.dll;dllopen shm:test_proxy [PATH] filename
accepts °any° file extension for the "descriptor file".

The elements actually needed in the descriptor file are far less than the "standard" .vmdk ones, example:

# Disk DescriptorFile
createType="twoGbMaxExtentFlat"
# Extent description
RDONLY 2880 FLAT "thesplit.iso1" 0
RDONLY 2880 FLAT "thesplit.iso2" 0
RDONLY 2880 FLAT "thesplit.iso3" 0
RDONLY 2880 FLAT "thesplit.iso4" 0
RDONLY 2880 FLAT "thesplit.iso5" 0
RDONLY 1784 FLAT "thesplit.iso6" 0
# The Disk Data Base


The above seemingly works fine :thumbsup:, no need for:

# version=1
#CID=fffffffe
#parentCID=ffffffff

nor for:

#DDBddb.virtualHWVersion = "3"

#ddb.geometry.cylinders = "16383"
#ddb.geometry.heads = "16"
#ddb.geometry.sectors = "63"
#ddb.adapterType = "ide"


The libvmdk is "sensible" to the size (in 512 bytes/sector) of the split parts, i.e. the values need to reflect the actual file sizes.

The imdisk connecting command needs an added -o cd to force the mount as CD/DVD:
imdisk -a -t proxy -o shm -o ro -o cd -f test_proxy -m Z:
:duff:
Wonko

#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 April 2015 - 10:06 AM

Ok, the attached little (EXPERIMENTAL/ALPHA) batch seems like working.

@ilko
You need to get current with the related thread about the proxy for libvmdk erwan.l created, here:
http://reboot.pro/to...oxy-for-imdisk/

@erwan.l
I am not too convinced about the way the proxy interacts with the user, but I will post my questions on the other thread, where they belong.

:duff:
Wonko

 

EDIT: Removed attachment see below for newer version.



#18 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 29 April 2015 - 10:18 AM

Ok, the attached little (EXPERIMENTAL/ALPHA) batch seems like working.

@ilko
You need to get current with the related thread about the proxy for libvmdk erwan.l created, here:
http://reboot.pro/to...oxy-for-imdisk/

@erwan.l
I am not too convinced about the way the proxy interacts with the user, but I will post my questions on the other thread, where they belong.

:duff:
Wonko

 

Just to be sure I get it right on the usage (quickly going thru your code) :

splitiso.cmd my.iso will create splitted files and also generate the vmdk descriptor file right?



#19 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 April 2015 - 10:41 AM

Just to be sure I get it right on the usage (quickly going thru your code) :
splitiso.cmd my.iso will create splitted files and also generate the vmdk descriptor file right?

Yep. :)
You will need rawcopy from Olof:
http://www.ltr-data.se/opencode.html/
http://www.ltr-data....les/rawcopy.zip

The limits are within "common sense" and batch math, batch has a range for positive integers between 0 and 0x7FFFFFFF i.e. 2147483647, so I use a couple of tricks (including the use of rawcopy) to avoid having to deal with size in bytes, so the theoretical size limit would be 2147483647 sectors (512 bytes in size), which would correspond to 2147483647*512=1099511627264 bytes, i.e. almost a Tb, but in practice the "sensible size" for ilko's request would be 4095M i.e. 4095*1024*1024=4293918720 bytes for the size of the (largest) chunk, and in 99.99% of cases that would produce:

  • a .isi file (the descriptor)
  • a .iso1 file (the first, 4095M chunk)
  • a .iso2 file (the second, less than 4095M chunk)

as I doubt :dubbio: that there are many .iso's larger than 8587837440 bytes, at the vey most there could be a third .iso3 file and the .iso2 would be "full size".

 

The batch is more "general" however, for the fun of it I split a smallish .iso in some 82 floppy sized .ison's and the proxy seemed like working fine as well, it could be even a way to (say) split a hard disk image on several USB sticks in case of need. :w00t:

 

:duff:

Wonko



#20 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 29 April 2015 - 10:54 AM

Yep. :)
You will need rawcopy from Olof:
http://www.ltr-data.se/opencode.html/
http://www.ltr-data....les/rawcopy.zip


I also have http://ltr-data.se/files/fsplitw.zipwhich probably could be handy in cases like this. It is also written back in 1997-1998 somewhere, so please bare with the graphics layout of it. ;)



#21 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 April 2015 - 11:27 AM

I also have http://ltr-data.se/files/fsplitw.zipwhich probably could be handy in cases like this. It is also written back in 1997-1998 somewhere, so please bare with the graphics layout of it. ;)

You see, when you want you can actually write nice little things, even GUI :) without the stupid .Net bloat ;).

 

I used the rawcopy because I am mis-using one of it's features", namely to exit the batch I detect when rawcopy, after the last valid "partial" file, creates a 0 byte one, but of course I could use fsplitw (that knows when to stop itself :)) to create the "right" files and then parse a DIR output to create the .isi descriptor, though seemingly it misses a /S or /Y parameter ("Silent" or "Yes, shut up and just recklessly do what you are told" :whistling:) for batch use.

 It could be however a good idea to make a separate batch file to create the descriptor from the already split (splitted? :unsure:) files :thumbup:.

 

:duff:

Wonko



#22 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 29 April 2015 - 11:40 AM

You see, when you want you can actually write nice little things, even GUI :) without the stupid .Net bloat ;).


Thanks, yes, at least 17 years ago apparently. :) Actually, I do lots of both .NET and non-.NET things today as well and I like to be active in both worlds. But graphical user interfaces have never been my area, with or without .NET.

I used the rawcopy because I am mis-using one of it's features", namely to exit the batch I detect when rawcopy, after the last valid "partial" file, creates a 0 byte one, but of course I could use fsplitw (that knows when to stop itself :)) to create the "right" files and then parse a DIR output to create the .isi descriptor, though seemingly it misses a /S or /Y parameter ("Silent" or "Yes, shut up and just recklessly do what you are told" :whistling:) for batch use.


Then I have a console version of the same thing. http://ltr-data.se/files/fsplit32.zip

#23 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 29 April 2015 - 12:56 PM

Find attached an early version of writeisi.cmd and a revised (fixed a possible nasty bug) 0.02 version of splitiso.cmd.

 

@Olof

Is there any difference in speed between rawcopy and fsplit32?  :unsure:

It obviously makes no difference with small files but when splitting larger than 4 Gb .iso's it may well make a difference.

 

:duff:

Wonko

 

Attached Files



#24 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 29 April 2015 - 12:56 PM

I have now built a few of the libyal libraries for use with devio and ImDisk:

http://reboot.pro/to...vio-and-imdisk/



#25 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1448 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 29 April 2015 - 01:06 PM

Find attached an early version of writeisi.cmd and a revised (fixed a possible nasty bug) 0.02 version of splitiso.cmd.

 

@Olof

Is there any difference in speed between rawcopy and fsplit32?  :unsure:

It obviously makes no difference with small files but when splitting larger than 4 Gb .iso's it may well make a difference.

 

Last time I looked closely at fsplitw/fsplit32 source code was probably many years ago so I didn't remember. But now I realize that they both read a whole file part into memory and then write it out to the corresponding split file. This might actually not be very good for splitting iso images etc. That design probably made sense when I wrote it, because back then the most common use was to split a large file to store the parts on 1.44 MB floppies... Oh well.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users