Simple File System

Monkey Forums/Monkey Code/Simple File System

Goodlookinguy(Posted 2011) [#1]
Edit 7/1/2012: A newer version of Monkey broke this code (I think). I haven't tried fixing it because I'm using Monkey JSON for my file system now. If it still works, great! If it doesn't, don't be surprised.

Edit 4/5/2013: An even newer version of my JSON file system can be grabbed here.

I had been working on some database specifications and realized that I couldn't use it in Monkey because it has multiple files have to be accessed and altered. So, I came up with this. It's kind of hacky at the moment because I wrote it extremely fast. It works nonetheless and is very, very simple to use.

Documentation (Generated by JungleIDE): http://nrgs.org/skyknitters/docs/FileSystemS.monkey.html



This is an example test file



This will be updated with cleaner code when I have the time. If you get any errors, fix any problems, have criticisms, or whatever, please tell me. I'll attempt to deal with it when I can.

EDIT 10/22/11: I'm working on a second version that will have iOS compatibility and cached reads, writes, edits, etc. It'll be a while longer though.


slenkar(Posted 2011) [#2]
looks nice, if i have a huge file.. say 500kb and a small file ...say 1kb

can i access the small file quickly? or does the big file slow it down (loading and parsing)

For example i could have a saved game of 500kb and an options file of 1kb


Goodlookinguy(Posted 2011) [#3]
Well, theoretically, with the way it's setup. The lower down on the file system it is, the slower it will be. If the 500kb file is first and the 1KB file is next. It should be able to access both files relatively fast.

It works like

Stored Index
/500kb [stored length: 512000b]
/1kb [stored length: 1024b]

Data starts at: Data Index (After file index)

To get to position of the file, it takes and adds all previous stored lengths of the files to find the slice location.

So, the data for /500kb would be at: Data Index to stored length of /500kb

For the /1kb file, it would be: Data Index + Length of /500kb file to stored length of /1kb


slenkar(Posted 2011) [#4]
interesting, i may use it later thanks


Goodlookinguy(Posted 2011) [#5]
You're welcome.

By the way, here's the quick documentation on it if you want: http://skyknitters.com/docs/FileSystemS.monkey.html

--
On this note, after getting some opinions from other people (around me), I'm going to rework how the directories and file index work. The new specifications will speed up file locating if directories are used to separate the data and if a lot of files are used. If very few files are used, it'll actually be a theoretical pinch slower. On the other hand, I'll be able to work some extra things into it easier, that I wanted to do with this one. E.g. A sort function, directory contents that read both files and directories, and data encryption and/or obfuscation.


dawlane(Posted 2011) [#6]
@Goodlookingguy
Have you tested this using ios? As I suspect you may have issues when encoding ints/bytes. Gfk had a problem with his filing system and posted it as a bug, but as it turned out the native class that deals with strings (NSString) on apple devices doesn't like non standard strings. A bit of googling will show up other examples of problems when dealing with apple's own implementation of a string class.

http://www.monkeycoder.co.nz/Community/posts.php?topic=1653


Goodlookinguy(Posted 2011) [#7]
I don't have a Mac yet and can't test anything with iOS yet. As soon as I get one, in the following months, I'll look into writing a custom string handler if necessary. Or maybe the creator of Monkey can make just that platform act like the rest. Seeing as we're limited to modifying ONE file, it seems unfair to stop us from making these sorts of systems which require the null character in the strings.


dawlane(Posted 2011) [#8]
Or maybe the creator of Monkey can make just that platform act like the rest.
From what Mark has posted I don't think it's on his list of priorities at the moment. So I would guess if any one is desperate they would have to implement their own solution either as a module or editing the monkey output file directly and then compiling their work.


Goodlookinguy(Posted 2011) [#9]
Yes indeed.

By any chance, do you know if this problem also affects the LoadState() function in the iOS? If not, I don't think the intended use for this file manager will be a problem.

Edit: Is it the actual string handling that can't handle null? If not, a simple base64 encode when saving and decode when opening would fix this, right? Just some thoughts in my head.


dawlane(Posted 2011) [#10]
By any chance, do you know if this problem also affects the LoadState()
I believe it does as the state file is stored as a string.

Edit: Is it the actual string handling that can't handle null? If not, a simple base64 encode when saving and decode when opening would fix this, right? Just some thoughts in my head.

Well from what information I have seen so far NSString isn't capable of handling malformed strings. I believe the usual method is to use a NSData object and parse the data for the relevant information that your looking for.

At the moment I'm still learning Objective-C and the Foundation Framework.

So perhaps some who is familiar with the Foundation Framework may be able to explain it better.


Goodlookinguy(Posted 2011) [#11]
Okay, thank you very much. I think I'll make an alternative version of this for that platform for the sake of everyone's sanity. I'll just use Base 36 to save space when reading how many bytes.

---
A bug fix for the DeleteFile method not changing the file count length updated.