Android application to manipulate sd image from the site

aaaa

The source code for tar from sash (stand alone shell) is small, worked 100% with RISC OS straight off, compared to the normal distribution of tar, it is a dream.
Edit:
It comprises of just one file, so I have linked it in case it is of interest.
Edit:
Your latest source has worked OK on the first small file I tried. (came back the same except for a “,” left on the end.)

aaaa

aaaaa

Sorry , I mean the “,” is left on the filename, the contents were OK.

aaaa

No I mean using squach on a file (actually I used squach/c) compresses it to squach/c,fca but when it decompress’s, the file name is now “squach/c,”
Trailing “,” on the filename. I haven’t tried clicking on the compressed file to see what the squash module does yet, last time I did this the result wasn’t good.
Edit: Mmm this time no action like there is no runtype set for &fca.

aaaa

I have rebooted, but still no action on the type &fca file, I’m sure the system took off on one of these files the other day,
trouble is I dont have any sample squash files around to try either.
I wonder if you have changed something in the file header that is making squash turn up it’s nose.
‘*Help module squash’ doesn’t show any commands, how does one create a squash file with the system?

aaaa

Ok, something fishy in the system by the looks, at some point the squash module /did/ start doing the expected thing, and no looking back, even the squached file I left to try after a reboot (that squash wouldn’t act upon) now expands.
I think this is a case of something running on my computer making squash shy rather than anything in your files, finding what causes or fixes this flakeyness will be difficult unless it repeats every time I boot.
Also, I probably should have done a full power off reboot, to get a better indication.

aaaaa

I haven’t tried this latest update, but something may have come to light with the extension problem.
It looks like there is an extra character in the file name it is expanding to
in hex, starting with the comma, 2C FF 66 66 66
The FF character shouldnt be there, sounds like the fff should be though.
Edit: or not, the input file was filetype &e1f

OK, I’ve found the !Squash application, I probably moved it out to make Apps less cluttered.
There is a runtype for squash then.

I think the &FF will be coming from the strcpy_s and the accompanning 256 stuff

aaaa

aaaa

I think it is the “%x” part of
snprintf(str, size, “%x”, val)
that is outputting the &ff &66 &66 &66
still looking at it

I think bz2 also can do this, though it is always used with tar for some reason.

Think of the unix philosophy. Tar archives files, bz2 compresses the result. There is no overlap. This is why a tar.bz2 file must be decompressed before being accessed. It’s a pain but that’s how it works. Nothing like a regular .zip where the individual files are compressed and can be accessed one by one at will.

Yes Rick, actually I might have got that wrong, it could be the gzip that can do directories on its own. I realise that tgz, txz and tbz are the normal use. (zipped tars)
When I made my tarctrl frontend I was faced with the prospect of replacing piping of the tarfile to xz bzip2 gzip with fork/execs, but I elected to do the job via the controlling obey file. This also alows me to alter the output names etc easily.
stdin/stdout piping runs into the same problems that stop the shell pipe “|” from working
The best we can do is redirect stdout to file and back.

To make things worse, when compiling and trying some of unix’s pipe schemes, the resulting binary crashes RISC OS hopelessly trying to open wimptasks. Very hard to get anywhere with.

aaaa

I have traced a problem back to the fread perhaps.

 printf          ("laddr = %s\n",laddr & 0xfff);

aaa

Thats better, now laddr = fff
Although the input file was filetype e1f, is that right?

itoa seems to be working, strftype string is = fff

aaaa

aaaa

strncpy_s looks bad,

laddr = fff
strftype = fff
#strncpy_s
dst_filename = ADFS::HardDisc.$.ttycat,@
#strcat_s
dst_filename = ADFS::HardDisc.$.ttycat,@fff
unable to open target file ’ADFS::HardDisc.$.ttycat,@fff’

Edit:
I’ve had to replace the strncpy_s with

strcpy_s       (dst_filename,256,src_filename);
dst_filename[(strlen(src_filename)-3)] ='\0';