Android application to manipulate sd image from the site

aaaa

aaaa

aaaa

aaaaa

This a command line tools i made quickly to test, it take one file as parameter, if the file ends with ,fca it will unsquash it, otherwise it will squash it to file.xx,fca.

http://h0bby1.eu5.org/riscos/squach.c

With !GCC I get

squach.o: In function `main':
squach.c:(.text+0x1504): undefined reference to `strcpy_s'

Omni is not very reliable lol I’m pretty sure it deleted several time a file that i didn’t intent to delete when there was the two file with same name and different ,ext/filetype.

Have you tried one of the free nfs clients and moonfish on RISC OS?

aaaa

aaaa

aaaaa

aaaa

Directory full. I don’t see how it can fit into a 2048 byte adfs dir record.

Directories stopped being limited to 77 entries of 10 letters each in 1998 when the ursula filecore was written and the directories can grow much bigger than 2k

aaaa

I updated the file to compile with gcc normally

Thanks and it does compile and work to a degree.
I have found it to lose data on the round trip and goes quite slow compared to bzip or lz4.
I haven’t tested it extensively, but It is a bit pointless if a file is different after compressing/decompressing.
If you haven’t seen this problem it must be related to the Iyonix/RISC OS /gcc but compression binaries have in the past worked the same on different platforms. The lz4 binary can be optimized for later arm chips, is fast, but spark is pretty fast, and has lots of benefits.
I’m not sure what you are trying to achieve exactly, I think compression takes longer than the network takes to move files unless you have lots of grunt. Tars or zips without compression can provide a speed up on a network by reducing the file count.
If you were to add encryption to compression it could only get worse.
I read an article comparing sshfs to nfs and it was half the speed in 5 out of 6 scenarios. And those tests would be done on late grunty hardware.
nfs isn’t considered fast either.

Cheers

They can be any size ? The code from the linux kernel is weird, and from i read in the prm, they still say the new file system use 2k directory entries and 10 letters names

You’re looking at the FileCore F Format directory structure, which has a limit of 77 and 2KB directory size. You need the FileCore F+ Format which was introduced with RISCOS 4 and supports a directory up to 4MB.

Unfortunately I don’t believe it’s ever been documented, so you may have to pick it apart from the FileCore BigDirCode source code.

aaaa

aaaa

aaaaa

Unfortunately I don’t believe it’s ever been documented, so you may have to pick it apart from the FileCore BigDirCode source code.

Awww, things like this make my head hurt. What’s with the two 01 markers? Yes, I can follow the code and the forward reference but really…!

  827: 90
  828:  [ Debug6
  829:         DREG    r4,"->(entry=",cc
  830:         BCC     %FT01
  831:         DLINE   ",not found)"
  832:         B       %FT02
  833: 01
  834:         BNE     %FT01
  835:         DLINE   " file ",cc
  836: 01
  837:         DLINE   ",found)"
  838: 02
  839:  ]

;-)

and 50% chances of data corruption over the network ?

Okay.
Whatever you are using isn’t working for you.
Try something else?

I can’t give suggestions as I just use a 1GiB FAT USB key (simplest way for me) but I did transfer a bunch of stuff off my old RiscPC using !Samba – Windows XP just saw it as a share and while a little slow (10mbit network card), it was pretty much draggy-droppy. Maybe there’s a 32 bit version of this?

aaaaa

Reliable ways to transfer big amounts of data over the network to a RISC OS client that I have tried: HTTP via NetSurf, FTP via FTPc, NFS via SunFish, SMB via LanMan98.

aaaa

If you know a better implementation that can be used on windows, linux and android to compress and decompress squash file, that is better than this one, i take :)

I think the reason I’ve had little to do with squash over the years, is the bias that network and what other platforms have imposed on what we use. Microsoft have never lifted a finger to support RISC OS formats at any time. If squash is highly optimised for RISC OS, I think your project has some merit, and yes it is mainly important that it works on the target platform.
One thing with the RISC OS compilers, is that it is easy to add ,xyz extensions so that riscos filetypes dont get lost.
For RISC OS side it is possible that the machine language source would compile on !GCC, as it supports asm now.
It would be nice to have a standalone binary that could be used with tar if squash /is/ fast.

I was asking what you were trying to do (poor choice of words) as you seemed to have moved on to directory structures from file compression, So does this mean squash supports compressing directories of files? I think bz2 also can do this, though it is always used with tar for some reason.

aaaa

Yes, tar /then/ compress is back to front if you want to access individual files. Just a thought though, that a tar file of squashed files may be more platform universal. Tar /does/ record the directory structure that you want doesn’t it?