My VFS has no fragmentation. The way it works is this:

1. VFS HEADER:

>name of vfs
>number of files

2. File headers.

>loop for number of files (from header)
>read in: file name, size, offset

3. File data

>loop through number of files
>Seek to offset, read in file.


it is pretty simple, really. THis is because each time the vfs is edited, the whole file is re-written (as opposed to a hard disk). There is no wasted space or fragmentation, but for very large VFSes, this could pose a problem (ie. it takes a long time to save... but if you''re only reading it in...)

For very large VFSes (EG. > 1GB) you might make your program only read the headers, then read the files in as necessary to save ram... You CAN do this because the headers are located at the start of the file, not interspersed through it.

not bad... encryption would slow it down, tho'', keep up the good work.

looks cool, can I just plug my file tree right away in it?

I have a /data directory so this would be perfect for me. So if the .vfs file in in ./ dir and then I add files like /data/level1/level.map etc... will it work?

I''m not sure.... Try it! I made it cull the directory of each file, though, because each file name is only 256 characters. Make this value, say 2048 characters (bigger file though). Then edit the code in AddFile - i think it''s this :

	//String to hold temporary data	string x = "";		//Loop through the whole string, character by character.	for (int i = s.size() - 1; i >= 0; i--) {		//Check the current character is not \ or /		if ( (s== ''\\'' || s == ''/'') )<br>		{<br>			//If it is, allow s to = x, and<br>			s = x;<br>			//Get out of the loop.<br>			goto l_out;;<br>		}<br>		else{<br>			//Otherwise, add s to the front of x.<br>			x = s + x;<br>		};<br>			<br><br>	}<br>	//If nothing found, just let s = x.<br>	s = x;<br> </pre>   </i>   

Not bad. Other features you might want to consider:

* Pluggable, nestable per-file filters. Different types of content might have different needs in terms of encryption, compression... possibly even forward error correction.

* MIME types, or similar metadata

* References to other archives (think of a multi-CD game... some files will need to be on all CDs, some will just be on one)

* Networkability (imagine streaming content using the same interface, from a server)

How appropriate. You fight like a cow.