[RC5] One file per block (etc)

Zypher zypher at clanusr.com
Wed Apr 28 19:19:51 EDT 1999

Two words: pak files.

Quake (and the programs that followed, such as Quake II and Halflife :) use

They have entire directory trees inside them (same structure as windows so
you can export easily) yet show as one file. (hence no cluster problem) And
they can be run from on the fly, adding and removing within the game etc
etc. (and from windows with pakeplr)  I'm sure theres another similar scheme
that isn't just used for 3D games by id, but the idea is the same. Somewhat
like zip files, but unlike zips more aimed for continuous usability. (if
you've ever gotten into the game slike I have, you know what I mean ;)
zypher at clanusr.com
"No, not bad spelling, bad typing"
----- Original Message -----
From: Chris Eaton <tridus at inforamp.net>
To: <rc5 at lists.distributed.net>
Sent: Tuesday, April 27, 1999 5:12 PM
Subject: Re: [RC5] If you were writing our next client, what would you put
in it?

> This is a good idea... except that if you have computers that buffer a lot
> blocks or are offline for a while and generate random blocks, you can end
> with thousands of files. On really large Windows hard drives, each file
> up several kilobytes of space (my fat32 drive is using 4k clusters right
> normal fat is a lot worse).. so you could have directories of blocks
> taking up several MB instead of the 130k or so they do right now.
> At 03:06 PM 27/04/99 , you wrote:
> >HAY!  That got me thinking.  Why not make the buffers directories?  If a
> >block is being worked on it is moved from 'undone' to 'working' so it
> >doesn't ever get lost accidentally.  Progress for a given block should be
> >written to it's file in 'working'.  Once it's done with a block it puts
> >in a 'done' directory.  Each block has a unique number so making filename
> >shouldn't be hard.  Each project could have it's own tree.  Something
> >like:
> >dnetc---+-rc5--+--undone
> >       |      |
> >       |      +--working
> >       |      |
> >       |      +--done
> >       |
> >       +-ogr--+--undone
> >       |      |
> >       |      +--working
> >       |      |
> >       |      +--done
> >       |
> >       +-des--+--undone
> >       .      |
> >       .      +--working
> >       .      |
> >       .      +--done
> >
> >The advantages of this I see:
> > - Fewer blocks permanently lost because blocks are always stored on disk
> >somewhere.  And you could backup the directories with little worry.
> > - Easier to implement sharing.  (If you can't create
> >then you don't delete the undone/12345678.blk and you try a different
> >block.)
> > - For those people who are sneakernetting, it'd be really easy to write
> >script to move all the done blocks to a floppy and put some new blocks in
> >undone.
> > - The working/* files could be use as checkpoint files.
> >
> >It'd also be nice to be able to resubmit a block if it was determined
> >wasn't successfully submitted for whatever reason.  Of course, this could
> >be a mess if some jerk wanted to resubmit lots of stuff that was already.
> >
> >--
> ></chris>
> >
> >If trees could scream, would we be so cavalier about cutting them
> >down?  We might, if they screamed all the time, for no good reason.
> >
> >--
> >To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
> >rc5-digest subscribers replace rc5 with rc5-digest
> >
> >
> >
> --
> "The game leaves out one much-needed feature: the ability to have
> Blizzard contact your friends and relatives every few days and let
> them know the reason you haven't been around."
>     -3d Gaming Net, referring to Starcraft: Brood War
> Chris
> http://home.inforamp.net/~tridus
> --
> To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
> rc5-digest subscribers replace rc5 with rc5-digest

To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest

More information about the rc5 mailing list