Spoiner(Split/Join/Recover) Maybe integration for dopus on icaros would be well

[paolone]

I am now copying file over a native Icaros installation, to see if SFS or maybe FAT32 filesystems correctly handle the file.

[salvatore]

I had the file on a key formatted in fat32, I could not move the file to another directory with sfs

[paolone]

Ehmmm

we've surely hit some boundary here... The split operation dies and brings whole AROS with itself
Notice also the file size. It should be 2,7 gigs, but...

[salvatore]

maybe we've reached a limit

[salvatore]

it seems to me that I had tried with a nightly build and everything worked, but we talk about two years ago about

hi Paolone

[salvatore]

Paolone I noticed by downloading directoryopus and starting it by default (yes I made my own distribution so for fun) there is a join and split command

[miker1264]

I need some time to download the pack file and test it on Icaros. If the file is too big, there is the chance you hit some AROS filesystem limitation. In the meanwhile, please have a read here, as promised:

          Splitting and rebuilding large files with Icaros 2.2.8   http://vmwaros.blogspot.com/2019/06/splitting-and-rebuilding-large-files.html

paolone,

Very good work setting up the user interface for the Split command. That's the process I go through setting up user input with my graphics programs. By the way the size of a floppy disk is 1440kb x 1024 bytes = 1,474,560 bytes. For an Amiga hd floppy it's larger. But that's a very good start.

Maybe the menu item could be "Split File" to match the length of other items and it's more specific. Splitting the large 2.7GB may fail due to improper memory allocation. You might look at the source code.

[miker1264]

Here is the contents of the Usage file from Sploiner. Maybe you can glean something useful from it as far what causes it to crash with large files.

It uses a Shadowfile to hold the contents. Take a look.

[paolone]

Here is the contents of the Usage file from Sploiner. Maybe you can glean something useful from it as far what causes it to crash with large files.

It uses a Shadowfile to hold the contents. Take a look.

Hi miker, I am afraid you have generously overrated my coding skills: actually, it's limited to some basic LUA scripting and running the commands ./configure and make. I would never be apple to modify a C source they way you suggest to me.

[miker1264]

Yes, but your scripting abilities are excellent.

If Sploiner is important and you'd like to include it in Icaros I could take a look at it this weekend to find out why it crashes on larger files. It's likely a memory allocation issue.

[paolone]

Yes, but your scripting abilities are excellent.

If Sploiner is important and you'd like to include it in Icaros I could take a look at it this weekend to find out why it crashes on larger files. It's likely a memory allocation issue.

You may do that after you're done with your persona projects which are, IMHO, more useful and interesting, than a splitting and rebuilding option I stubbornly decided to add to an interface than many people even avoid to use.

[miker1264]

Your tremendous efforts are greatly appreciated.

[miker1264]

paolone,

There is a small app on Aminet called MUIJoiner10. It's based on MUI and it has 4 buttons: Join,Split,Prefs,Quit.

Maybe a customized Split/Join app like that would work well? MUI-Joiner seems to work. Check it out when you have time.

[salvatore]

the problem is that maybe with very big files the application doesn't work because of the file system, horewer if an essential mui interface would be nice to have it

[miker1264]

When I have a few moments of free time I will put together an MUI joiner like the one I described.

It will have four buttons. But I will set the I initial size to zero so the prefs will pop up asking for Size? I will also include a checkbox for "Custom" that will join two files such as icon images.

I have two small functions called Copy_File and Copy_File_Append that will do the hard work. They both work very well. I use them in Icon Factory.