First of all, however, let's talk a little about Sploiner. Sploiner is a one-command utility wich basically performs three different functions: splitting large files into little ones, rebuilding files from their parts and even recover the original file if a part is missing. I'll leave for now the recovering part, focusing on the other two. Sploiner can split a large file with a command like this:
Sploiner SPLIT filename -n <-s size> <-o outputname>
the -n option does not produce shadow files, sploiner's CRC control files it can use to rebuild a part of a file, if missing. The -s and -o options are more interesting because they actually produce part files, with filename and size chosen by user. For instance, let we split the video file from Josh Woodward coming in MyWorkspace/Videos in double-high-density floppy format (2,88 MB):
On the contrary, a syntax like this:
Sploiner JOIN basename AS namefile
would do the exact opposite. The basename in the former example would be jv_video, while the namefile should be JoshWoodward_InvisibleLight.mpg. Quite cosy, don't you agree? Yes, it is. But now let's transpose all this into a point'n'click GUI like Magellan one. We have a file to click on, and we wish to split it. How should we handle this?
First of all, I thought that asking the user for a parts namefile would have been a waste of time. The original large file already has a name, so why shouldn't we use it as well? Maybe because some of AROS filesystems still expect a 32-character lenght name, and simply adding the _PART.xxx suffix might exceed the quota. So I thought that the best solution would have been taking the first 22 characters of the original name and to append the _PART.xxx postfix to it. In our example, JoshWoodward_InvisibleLight.mpg would be splitted into several JoshWoodward_Invisible_PART.xxx name. But how many parts? That's a question only users can answer to. My solution to this problem has been using a RequestString instance, suggesting the size of a common high-density PC floppy disk (about 1,44 MB), with some bytes left. User can change this value to fit the size of a double-high-density one, or the size of a CD-R (700000000) if the original file is particularily large. At this point, we've all that we need to perform the action:
My script also creates a little text file called <basename>_PART.name which contains the name of the original file. Why? Because if you don't know it already, you may have some problems rebuilding it. Let's think about this scenario: a friend of yours gives you all the part of a video, but you don't know how the video was named in the first instance. Without further information, you wouldn't be able to name it correctly. The _PART.name file resolves this issue and tells Icaros how to name it after rebuilding. Operation that is performed like this:
In this case, only a question is proposed to users: should we keep the part files or not, after the join operation? If we choose to delete them, only the rebuilt file will be kept.
