ArcFS or SparkFS

53 views
Skip to first unread message

Roger Clark

unread,
Nov 4, 1993, 10:02:37 AM11/4/93
to
ArcFS or SparkFS - which one to use ?

I'm confused (aren't I always). Here we are with two archiving programs, which
are both good, but incompatible. Spark is always used for ftp sites, but ArcFS
is used on all the magazine cover discs. If I have say Spark reader
module loaded, and then (for instance) mount a magazine cover disc, I get
sometimes fatal crashes. So if I want one for home use, which one should I get.
I know ArcFS quotes decompression speeds, is it quicker than SparkFS ? They
both support Image Filing systems, which would be nice. Which one is more
memory efficient - or are they both bad/good ?

Comments anyone ?

Roger

--------------------------------------------------------------------------------rcl...@bt-sys.bt.co.uk
--------------------------------------------------------------------------------


Denis Howe

unread,
Nov 5, 1993, 5:01:28 AM11/5/93
to
In article <CFz34...@bt-sys.bt.co.uk> rclark@xenon (Roger Clark)
asks:

> ArcFS or SparkFS - which one to use ?

I manage pretty well with a free, read-only ArcFS and an old !Spark
v2. I also use John Kortink's !PackDir for private archiving because
it's fast. Finally, I use Frank Lancaster's tar and compress and my
!Backup for regular backups. I heard a long time ago that David
Pilling was working on Spark v3. Is it available now? Is it worth
getting?
--
Denis Howe <d...@doc.ic.ac.uk>
The Free On-Line Dictionary of Computing
Gopher/FTP wombat.doc.ic.ac.uk (146.169.22.42)

py2...@cen.ex.ac.uk

unread,
Nov 5, 1993, 5:13:08 AM11/5/93
to
In article <CFz34...@bt-sys.bt.co.uk> rcl...@bt-sys.bt.co.uk writes:
>ArcFS or SparkFS - which one to use ?

I have been using ArcFS 2 for several months, and I have been very pleased with
it. It really does work well as an image filing system. I always use it on
16bit compression, which has dramatically increased the amount of stuff I get
on my A4's hard disc, although it does eat RMA something chronic. It uses
rather less memory in 12bit mode, and can be set to any number between 12 and
16. One improvement I think could be made is to give back the memory it has
used to the free slot after it has finished with it, rather than leaving it in
the RMA. I am forever dragging my RMA slider back by 1.5Mb or so. This is,
however, the only slightly negative thing I can think of about ArcFS 2.

I have played a little with SparkFS (I don't think it was a very recent version)
and I seem to remember that it stored files as individual compressed files
within an application directory. This probably is slightly faster than ArcFS
(though not much, I shouldn't think), but it does mean that each file will have
some free space in its last sector (unless it is very lucky), and therefore a
little of the saving made by compressing the file will be wasted again. Also
each SparkFS 'application' has several support files (sprites, run files, etc.)
which will take up space, and there will be at least one directory, requiring
a catalogue, inside it, or probably more if you compress something with
subdirectories. ArcFS suffers from none of these problems, as files are
archived in a single file, with auto-compression (optionally), and no need for
support files.

I shall be continuing to use ArcFS, and would reccomend it without reservation
for users with at least 2, and preferrably 4Mb. This is not to knock SparkFS -
I simply don't know enough about it to do that, and the above is mainly
speculation.

Tim

Steffan Corley

unread,
Nov 5, 1993, 6:26:30 AM11/5/93
to
In article <CG0KD...@cen.ex.ac.uk> py2...@cen.ex.ac.uk writes:
>In article <CFz34...@bt-sys.bt.co.uk> rcl...@bt-sys.bt.co.uk writes:
>>ArcFS or SparkFS - which one to use ?
>
>I have played a little with SparkFS (I don't think it was a very recent version)
>and I seem to remember that it stored files as individual compressed files
>within an application directory.

SparkFS can either do individual compressed files within an application
directory (which is less dangerous in terms of data loss, and also
faster), or use an image filing system, similar to (but not the same as)
that used by ArcFS.

I would expect compression ratios to be about the same, and would guess
ArcFS is slightly faster as it is optimised for a particular Archive
format rather than understanding many.

However, for me the great advantage of SparkFS is that it understands
(almost) any archive I throw at it, regardless of what machine it was
produced on. This means that when I get any files off the net, I can
decompress them with SparkFS, even if they are PC sound/graphics files
or MAC font files.

SparkFS also reads (but does not write, at least in my version) ArcFS
archives. This means that it can be quite happily used with most cover
discs if:

a. You don't give the disc a chance to boot itself (hold down control
when you open it).

b. You open the archive directly rather than run the menu program.

As far as I know, the above comments do not apply to the Acorn User
cover disc, which does not make any special attempt to load ArcFS if you
already have SparkFS loaded.

I think that's everything. Basically I am a very happy SparkFS user.
However, as I haven't got ArcFS I can't judge it.

Steffan.

Disclaimer: I speak for noone (including myself) and have no connections
with anyone.

Robin Watts

unread,
Nov 5, 1993, 1:08:25 PM11/5/93
to
In article <CFz34...@bt-sys.bt.co.uk> rclark@xenon (Roger Clark) writes:

ArcFS or SparkFS - which one to use ?

I'm confused (aren't I always). Here we are with two archiving programs,
which are both good, but incompatible. Spark is always used for ftp sites,
but ArcFS is used on all the magazine cover discs.

Bit of history called for here I think.

Originally there was spark, and it was good. It archived stuff in archives
according to its own special fileformat. These I shall call Sparkives, and
the mighty Pilling gave unto them the filetype DDC.

And some people said: 'Yay, it is good, but what happens if I want to give
archives to my mates?'. So the Pilling gave unto them SparkPlug, which
decompressed only.

Then came Spark 2, and it was better - it introduced a modified version of
the Sparkive that could hold more. Also, it could read and write some
'foreign' archive types. So Spark 2 could read both Spark 1 and Spark 2
files, wheras Spark 1 could read only a subset of the Spark 2 files.

And then there was SparkPlug 2. And thou canst guess what this did.

And someone saw it and said 'Yes, it is good, but it could be better
- wouldn't it be nice if it allowed you to run applications from
Archives.' So he wrote ArcFS 1.

All it did was allow you to access spark archives as a filing system.
So you could actually run applications from within archives. But
this was written in C, and was slow, and expensive on memory, as
the entirety of open files were held in RAM as they were accessed.

Then came ArcFS 2. This was 'better', as it also archived stuff, but
in a different format, but still maintained the ability to read
Spark files. It was also written in ARM Code, and so was much faster.

And Pilling Saw that this was good, and saw also that spark could
also be written in this way and could handle all manner of new
archive types. So he wrote SparkFS.

And SparkFS was dead good. It coped with every archive type known
to man (almost), and was extensible, so as people can write their
own types. And it runs as archives. And it offers the best compression
ratios currently around on the Arc. And it supports gzip. And I
bought a copy ( :-) ). And it costs #23.00, (with 6 pounds off if you
have Spark, and another 6 if you have ArcFS) from David Pilling.

The only drawback is that SparkFS cannot write and read ArcFS archives
(though I believe it can read them)

Now, Spark 2 has been updated in parallel with SparkFS, so it can cope
with some of the same formats (Things like McStuffit may not be
implemented. It still costs 5.99, and comes free with SparkFS.

SparkPlug is freeware, and copes (decompressing) with the same as Spark.
Can be found on newcastle.

ArcFS 2 read only is freeware (and is the one found on mag discs, cos it
is the smallest executable.)

ArcFS 2 read/write is available from Software 42, for I know not how much.

Overall, if you are just looking for an Archiver, it is a toss up between
the two. if you are looking for some thing to cope with Foreign Archives,
then you need something from the Spark Family. SparkFS is worth the
dosh if you can afford it.

If I have say Spark reader
module loaded, and then (for instance) mount a magazine cover disc, I get
sometimes fatal crashes. So if I want one for home use, which one should
I get.

IMHO, Spark or SparkFS. Buy Spark, and upgrade if you need it. It costs
the same in the long run.

I know ArcFS quotes decompression speeds, is it quicker than SparkFS ? They
both support Image Filing systems, which would be nice. Which one is more
memory efficient - or are they both bad/good ?

They are both about the same memorywise, but SparkFS can use the Sprite
Pool rather than RMA, and so is much more memory freindly as comes
to defragmentation.

Comments anyone ?

None that I can think of :-)

Robin

Stephen Burke

unread,
Nov 5, 1993, 4:43:08 PM11/5/93
to
In article <1993Nov5.1...@aisb.ed.ac.uk>, stef...@aisb.ed.ac.uk (Steffan Corley) writes:
> I would expect compression ratios to be about the same, and would guess
> ArcFS is slightly faster as it is optimised for a particular Archive
> format rather than understanding many.

I did some tests with SparkFS, and concluded that the most recent Zip method
(deflation?) is both faster than Compress and produces somewhat smaller files.
Does anyone else have an opinion on the best method for general use?

--
e----><----p | Stephen Burke | Internet: bu...@vxdesy.desy.de
H H 1 | Gruppe FH1T (Liverpool) | DECnet: vxdesy::burke (13313::burke)
H H 11 | DESY, Notkestrasse 85 | BITNET: BURKE@DESYVAX or SB2@UKACRL
HHHHH 1 | 2000 Hamburg 52 | JANET: s...@uk.ac.rl.ib
H H 1 | Germany | Phone: + 49 40 8998 2282
H H 11111 | HERA, the world's largest electron microscope!

Simon Glass

unread,
Nov 5, 1993, 3:47:58 PM11/5/93
to

> I have played a little with SparkFS (I don't think it was a very recent version)
> and I seem to remember that it stored files as individual compressed files
> within an application directory. This probably is slightly faster than ArcFS
> (though not much, I shouldn't think), but it does mean that each file will have
> some free space in its last sector (unless it is very lucky), and therefore a
> little of the saving made by compressing the file will be wasted again. Also

This is the 'spark dir' option. I tend to use the archive file method - as
you say, it saves space. Also, SparkFS supports zip deflation which can
compress ordinary compressed files (such as squeezed rumimages) by an
additional 20%. Great when squeezing stuff onto floppies. Also supports
arcfs, packdir, arj, lzh, mcstuffit, etc.

I have a great admiration for SparkFS, it is a very stable and capable
product. It is always on my icon bar.

> each SparkFS 'application' has several support files (sprites, run files, etc.)
> which will take up space, and there will be at least one directory, requiring
> a catalogue, inside it, or probably more if you compress something with
> subdirectories. ArcFS suffers from none of these problems, as files are
> archived in a single file, with auto-compression (optionally), and no need for
> support files.

Same with SparkFS.

> I shall be continuing to use ArcFS, and would reccomend it without reservation
> for users with at least 2, and preferrably 4Mb. This is not to knock SparkFS -
> I simply don't know enough about it to do that, and the above is mainly
> speculation.

SparkFS stores its data in the sprite area, which is nice since it doesn't
fragment your RMA. I understand that ArcFS does/will do this too. Also I
heard that ArcFS 2 is slightly faster than Spark - although for speed I use
Packdir anyway. SparkFS is great for multitasking reading of Packdirs...

Anyway, you have my vote...

--
Simon

Sig line trunca

Simon Burrows

unread,
Nov 6, 1993, 7:09:09 AM11/6/93
to
In article <CT93008.93...@black.ox.ac.uk> ct9...@black.ox.ac.uk (Robin Watts) writes:
>
>ArcFS 2 read/write is available from Software 42, for I know not how much.

ArcFS 2.20 is available from Vertical Twist. Software 42 hasn't "closed down"
or "gone to the wall" as suggested in some magazines, it has turned into a
software development company, and Vertical Twist / GamesWare are handling
the sales and marketing of most of their existing products. All three of the
partners in Software 42 Developments have Email access, as does Mark Smith,
author of ArcFS. David Pilling (of Spark/FS fame) also has Email access.

-- Simon
-- Disclaimer: blah

Herbert zur Nedden

unread,
Nov 9, 1993, 1:14:30 PM11/9/93
to
rclark@xenon (Roger Clark) writes:

> ArcFS or SparkFS - which one to use ?
>
> I'm confused (aren't I always). Here we are with two archiving programs, which
> are both good, but incompatible. Spark is always used for ftp sites, but ArcFS
> is used on all the magazine cover discs. If I have say Spark reader
> module loaded, and then (for instance) mount a magazine cover disc, I get
> sometimes fatal crashes. So if I want one for home use, which one should I get.
> I know ArcFS quotes decompression speeds, is it quicker than SparkFS ? They
> both support Image Filing systems, which would be nice. Which one is more
> memory efficient - or are they both bad/good ?

The reason ArcFS is used on cover discs is that the read/only filing system is
freeware or public domain. On the other hand, I personally prefer SparkFS. I
never had any problems with it and appreciate especially the much better com-
pression ratio. Furthermore you can put an application into an archive and have
that archive look like the application, i.e. it is displayed with its own icon!

As far as I remember SparkFS is faster that ArcFS and Cfs, the latter being another
compression tool with a different approach - as a matter of fact an approach, I do
not like.

I think SparkFS is better on memory management. At least the old ArcFS versions
decompressed the files into the module area whereas SparkFS uses the system sprite
area which it can increase and reduce.


Herbert.

------------------------------------------------------------
Herbert zur Nedden e-mail: h...@archh.hanse.de
snail : Alte Landstr. 21
Headquarter of the D-22962 Siek
German Archimedes Group Germany
Info: g...@archh.hanse.de phone: +49 - 41 07 - 99 00
------------------------------------------------------------

Bernard Jungen

unread,
Nov 12, 1993, 8:09:10 AM11/12/93
to

In article <9V10D...@archh.hanse.de>, h...@archh.hanse.de (Herbert zur Nedden) writes:
[stuff deleted]

|> As far as I remember SparkFS is faster that ArcFS and Cfs, the latter being another
|> compression tool with a different approach - as a matter of fact an approach, I do
|> not like.

What? SparkFS faster than the others? Must be kidding.

|>
|> I think SparkFS is better on memory management. At least the old ArcFS versions
|> decompressed the files into the module area whereas SparkFS uses the system sprite
|> area which it can increase and reduce.

Personally I don't like SparkFS memory management. You know I've not the chance to
have a hard disk and SparkFS uses temp files! It doesn't report any error if it is
short of disk space and just truncates the temp file!
One thing I REALLY DON'T like about it is that it uses a temp file if the files to
decompress don't fit in the sprite area, instead of just relying on the FS's asking
the user to swap disks or so...
And what it does to the sprites already present in the sprite area...

Although it's useful because it can cope with a lot of formats...


Bernard Jungen.
jun...@Informatik.TU-Muenchen.DE (temp)
Member of BASS.

Simon Burrows

unread,
Nov 13, 1993, 6:57:57 AM11/13/93
to
In article <9V10D...@archh.hanse.de> h...@archh.hanse.de (Herbert zur Nedden) writes:
>> ArcFS or SparkFS - which one to use ?
>
>The reason ArcFS is used on cover discs is that the read/only filing system is
>freeware or public domain. On the other hand, I personally prefer SparkFS. I
>never had any problems with it and appreciate especially the much better com-
>pression ratio.

You say the only reason is because it is Freeware? Not true. The read-only
version of ArcFS takes up less space on disc, and is easier for a novice
to use (you'd have to admit that the UI to SparkFS takes some getting used to).

The much better compression ratio? Are you using the latest ArcFS version 2.20?
Are you using a standard archive type in SparkFS, or an algorithm such as
Zip Deflate?

>As far as I remember SparkFS is faster that ArcFS and Cfs, the latter being
>another compression tool with a different approach - as a matter of fact an
>approach, I do not like.

Try the latest versions of *both* packages before comparing them.

>I think SparkFS is better on memory management. At least the old ArcFS
>versions decompressed the files into the module area whereas SparkFS uses
>the system sprite area which it can increase and reduce.

Ah, you're basing your comments on an old version of ArcFS. Not the fairest
way of comparing two products. I'm a satisfied user of both ArcFS2 and SparkFS,
and was happy to pay for both -- however each has its strengths & weaknesses
so I'm not ready to write off either package yet.

-- Simon
-- Disclaimer: all opinions are entirely my own (you can guess the rest)

Simon Glass

unread,
Nov 12, 1993, 8:39:10 PM11/12/93
to

>
> Personally I don't like SparkFS memory management. You know I've not the chance to
> have a hard disk and SparkFS uses temp files! It doesn't report any error if it is
> short of disk space and just truncates the temp file!

Oh dear

> One thing I REALLY DON'T like about it is that it uses a temp file if the files to
> decompress don't fit in the sprite area, instead of just relying on the FS's asking
> the user to swap disks or so...

How can it decompress a file if there is not enough memory? I do not follow
you

> And what it does to the sprites already present in the sprite area...

Leaves them alone

> Although it's useful because it can cope with a lot of formats...

Particularly zip deflate

Stephen Burke

unread,
Nov 14, 1993, 2:03:41 PM11/14/93
to
In article <2c2i45$5...@unicorn.ccc.nottingham.ac.uk>, s...@cs.nott.ac.uk (Simon Burrows) writes:
> You say the only reason is because it is Freeware? Not true. The read-only
> version of ArcFS takes up less space on disc, and is easier for a novice
> to use (you'd have to admit that the UI to SparkFS takes some getting used to).

Less space than what? (since there is no read-only version of SparkFS). And
the UI (for reading) is identical for both, i.e. you just click on the archive.

> Are you using a standard archive type in SparkFS, or an algorithm such as
> Zip Deflate?

What's wrong with using zip deflate?

> way of comparing two products. I'm a satisfied user of both ArcFS2 and SparkFS,
> and was happy to pay for both -- however each has its strengths & weaknesses
> so I'm not ready to write off either package yet.

So can you post some statistics - compression ratios and time to
compress/decompress for "typical" files? Memory usage? Pros and cons of each?

J.M. East

unread,
Nov 5, 1993, 5:13:46 AM11/5/93
to
In article <CFz34...@bt-sys.bt.co.uk>, rclark@xenon (Roger Clark) writes:
> ArcFS or SparkFS - which one to use ?
>
> I'm confused (aren't I always). Here we are with two archiving programs, which
> are both good, but incompatible. Spark is always used for ftp sites, but ArcFS
> is used on all the magazine cover discs. If I have say Spark reader
> module loaded, and then (for instance) mount a magazine cover disc, I get
> sometimes fatal crashes. So if I want one for home use, which one should I get.
> I know ArcFS quotes decompression speeds, is it quicker than SparkFS ? They
> both support Image Filing systems, which would be nice. Which one is more
> memory efficient - or are they both bad/good ?
>
> Comments anyone ?
>
> Roger
>
Yes, I've got both - & I don't use them!!! Simply, CFS is perhaps the best
to use I've found so far, and is easy as well. The compaction ratio is also
really good, and it works quite fast.

JAMES.

Andrew DeQuincey

unread,
Nov 15, 1993, 6:30:22 AM11/15/93
to


I use Memphis as a temporary filing system for SparkFS. It is much more reliable
than anything else I have tried. Its a resizable RAM disc, BTW.


--

adq Email: term-time : at...@dcs.ed.ac.uk
non-term-time: the...@arcade.demon.co.uk

John Robinson

unread,
Nov 15, 1993, 8:44:02 PM11/15/93
to
In article <CGJ6M...@dcs.ed.ac.uk>, at...@dcs.ed.ac.uk (Andrew DeQuincey) writes:
|> I use Memphis as a temporary filing system for SparkFS. It is much more reliable
|> than anything else I have tried. Its a resizable RAM disc, BTW.

Hang on... Memphis uses the sprite area to implement the (automatically
resizing) resizable RAM disc. And SparkFS uses the sprite area for temporary
storage. How the hell does using Memphis help anything at all???

John.
--
Disclaimer: I know only that I know nothing

Bernard Jungen

unread,
Nov 16, 1993, 11:17:50 AM11/16/93
to

In article <9vS3s...@sglass.demon.co.uk>, sgl...@sglass.demon.co.uk (Simon Glass) writes:
|> In article <1993Nov12....@Informatik.TU-Muenchen.DE> jun...@Informatik.TU-Muenchen.DE (Bernard Jungen) writes:
|>
|> >
|> > Personally I don't like SparkFS memory management. You know I've not the chance to
|> > have a hard disk and SparkFS uses temp files! It doesn't report any error if it is
|> > short of disk space and just truncates the temp file!
|>
|> Oh dear

What should I understand?

|>
|> > One thing I REALLY DON'T like about it is that it uses a temp file if the files to
|> > decompress don't fit in the sprite area, instead of just relying on the FS's asking
|> > the user to swap disks or so...
|>
|> How can it decompress a file if there is not enough memory? I do not follow
|> you

How then it's possible to decompress a 2 meg file using only a 200K buffer?

|>
|> > And what it does to the sprites already present in the sprite area...
|>
|> Leaves them alone
|>
|> > Although it's useful because it can cope with a lot of formats...
|>
|> Particularly zip deflate
|>
|> --
|> Simon
|>
|> Sig line trunca

Simon Glass

unread,
Nov 16, 1993, 3:15:06 PM11/16/93
to
In article <CG0K...@compsci.liverpool.ac.uk> u1...@csc.liv.ac.uk (J.M. East) writes:

> Yes, I've got both - & I don't use them!!! Simply, CFS is perhaps the best
> to use I've found so far, and is easy as well. The compaction ratio is also
> really good, and it works quite fast.
>
> JAMES.

Well I have the lot, and I use SparkFS. CFS 1.17 has caused me a bit of
grief. You are supposed to be able to compress a directory onto itself, like
Squash, but in RISC OS 3 this does not multitask (no big deal). Also, CFS
creates it's own version of Filer_Action which has a minor but
impossible-to-get-around-without-quitting-cfs bug in it (this has been fixed
by a CC patch). Finally I found its RMA use a little hard to swallow,
particularly with DDT buggering it up as well. SparkFS uses the sprite area
which is a better move.

IMhO CFS is 99% there, but needs more of a user's perspective to creep ahead
of the competition.

Herbert zur Nedden

unread,
Nov 22, 1993, 11:22:16 AM11/22/93
to
jun...@Informatik.TU-Muenchen.DE (Bernard Jungen) writes:

> In article <9V10D...@archh.hanse.de>, h...@archh.hanse.de (Herbert zur Nedden) writes:
> [stuff deleted]
> |> As far as I remember SparkFS is faster that ArcFS and Cfs, the latter being another
> |> compression tool with a different approach - as a matter of fact an approach, I do
> |> not like.
>
> What? SparkFS faster than the others? Must be kidding.

Well, don't compare ZIP deflation with some less efficient algorithm, please! That one
indeed take quite a while, but the result is quite good.
Compare equivalent algorithms and you'll see... Things might be a bit different using
floppy discs only, though!

> |>
> |> I think SparkFS is better on memory management. At least the old ArcFS versions
> |> decompressed the files into the module area whereas SparkFS uses the system sprite
> |> area which it can increase and reduce.
>
> Personally I don't like SparkFS memory management. You know I've not the chance to
> have a hard disk and SparkFS uses temp files! It doesn't report any error if it is
> short of disk space and just truncates the temp file!
> One thing I REALLY DON'T like about it is that it uses a temp file if the files to
> decompress don't fit in the sprite area, instead of just relying on the FS's asking
> the user to swap disks or so...

Well, fortunately I can't say anything about running the Arc without a hard disc. In that
case CfS *might* indeed be the better solution. I can't tell, though.

> And what it does to the sprites already present in the sprite area...

Put it this way: SparkFS, LaserDirect and Memphis use the system sprite area (ssa). I never
had problems with SparkFS and LaserDirect using the ssa at the same time and my friend Olaf
runs SparkFS together with Menphis. No problems either. You get hassles from a few games
who kill the wohle ssa, though .... but what the heck!

>
> Although it's useful because it can cope with a lot of formats...

True, indeed!

Reply all
Reply to author
Forward
0 new messages