My own archive format

[noeska]

after lots of bugfixing a better working version. The TFileStream withing TFileStream now works. Phew :-)
Now i better go clean up the source as that is a real mess right now. :-(

Anyway here is the download: http://www.noeska.net/downloads/Virt...stemAlpha4.zip (mpl license)

[EDIT]i hope this download works as i seem to have mistyped the previous ones[/EDIT]

[noeska]

Another version: http://www.noeska.net/downloads/Virt...stemAlpha5.zip

So for this release i could use some alpha testers...

bug 1 is already there: the xth directory entry is written in the wrong block at the wrong position? Why?

[EDIT] Bug fixed so: http://www.noeska.net/downloads/Virt...stemAlpha6.zip [/EDIT]

[noeska]

Now it is alpha 7 time already. Not it is also possible to delete files. Deleted blocks are reused again.
This only works for tvirtualfilestream bases access to the tvirtualfilesystem. So writedata (and readdata) need to be rewritten to use a tvirtualfilestream. Besides making reusing deleted blocks work with those it save some double code.
With reusing deleted block the tvirtualfilesystem may end up to be defragmented. Hmm how to write such an thing?

Who are willing to give this alpha version a test run? It comes with an basic example i use for testing.
I still have to give the virtualfilesystem a proper name and i am out of ideas so suggestions are welcome.

Download: http://www.noeska.net/downloads/Virt...stemAlpha7.zip

[arthurprs]

noeska, why you implemented it using blocks, any special reason?

[noeska]

the alternative would be complete files, but that would lead to disaster with deleting and reusing filespace.

With blocks it is relative easy deleting and reusing filespace. Also a file can grow in size without the need of moving it completely. Addressing is also relative simple because of the static size of a block within a virtualfile system. With complete files you dont have that advantage.

The only drawback is waste of space with file smaller then the blocksize and defragmentation.

E.g. also real filesystems like fat en ntfs use blocks.

But if you have another alternative besides using block do let me know.

[Brainer]

But if you have another alternative besides using block do let me know.

Yip, I'd like to hear about such, too.

[arthurprs]

I usually put a header with some signature and filecount, then some description structures * filecount and finally the files =s

it works fine to pack game files :?

[noeska]

yes, but i want to do more then pack game files. This is way more dynamic. Allowing to change files within the virtual file system without having to recreate the data file. E.g. it should be possible to use it as a datastorage for a database.

[arthurprs]

yes, but i want to do more then pack game files. This is way more dynamic. Allowing to change files within the virtual file system without having to recreate the data file. E.g. it should be possible to use it as a datastorage for a database.

uhm, interesting.

[Brainer]

I've got the same aim as noeska, I'm not interested in pack files, I want to do more than that.

Anyway, I'm not sure there's any other way to store files than just diving them into blocks. Of course you can write them at once, but then removing these from package would mean copying a file to the end of the package file and then truncating its size by the size of the removed file. And this is well-known to be a slow operation, especially when talking about "bigger" files (>1 GB).

And AFAIK, fragmentation cannot be avoided. I just can't think of any other way of storing files inside a package.