In C, to find the length of a string, use strlen. char *s; . . . if (strlen(s) <= 5) { ... strlen is a very crude function it starts at the char pointed to by s, and then counts forward until it finds a null byte '\0'. s -> "HELLO\n"; strlen(s) = 5. (It doesn't actually count the null byte, it just counts up to it.) strcmp (a,b) a and b are char *'s. It counts forward on a and b until they disagree on a character or until one or both hit a null byte. if a comes before b a negative int is returned. If a comes after, a positive int is returned, and if they're equal 0 is returned. memcmp (a,b,n) is the same, except it doesn't stop at null bytes. It stops when n characters have been examined. If you don't store a file contiguously, you have to store it in blocks. One way to do this is to store the blocks as a linked list. Each block points to the one that comes after it. The problem with this, is that you lose random access capability on the file. If you're in one block and you need to find another block, you've got to jump to every block in between to find the one you need. Another way do it is with in an index. You have an array of pointer and if you need to jump to block 7, you look up that pointer in the array and jump there, and this is very fast. One of the issues that crops with all file systems is "consistency". Do all the pointers go to where they should go? Does the collection of bytes on the disk "actually" correspond to a correct file system? Let's say you yank a flash drive out of the USB port without ejecting it first? You run the risk of the data on the drive not being in an acceptable format. If something was being written at the time you yanked it, then that partially written thing may not be in a consistent state. Or, let's say the power cut out while you were writing to the disk, so there's a partially written thing. Or--and this is a real thing--a bit spontanously flips. So, how do you get around this? One way is to have redundancy in the storage for data recovery. Some systems allow you to correct small errors. But, in general, you may have to run a system for an integrity check, possibly with the ability to correct it. For example, due to a power failure, the pointer from block 1 of a file to block 2 is now corrupt and doesn't actually point to block 2. Did I just lose the file? Maybe not. Because, if you're smart, block 2 had a pointer going back to block 1. So, if you scan the whole disk, and find the block pointing back to block 1, you can then correct that pointer and get your file back. Different systems have different mechanisms for doing this. However we store our files, contiguously or in blocks, we've got to make sure that we can allocate space when we need it from a part of the disk that's not already storing anything. Free blocks and used blocks? I generally have a mechanism to tell me where the free space is and the used space. If all the blocks are the same size, I can store pointers in the blocks. The free space pointer points to a block of free space, which points to the next block of free space, and so forth, like a linked list. I can then push and pop blocks of free space from this list like a stack. If we're using blocks of the same size, this is a pretty easy way to go about it. But if we're requesting varying sizes of space, then we need something more sophisticated. Perhaps each section of free space knows its own size, so you can look up how much free space is available in the particular section. Best-Fit and First-Fit. Best-Fit goes through the available free space and allocates space from the smallest region large enough to accomodate the request. First-Fit goes through the free space and allocates space from the first region it finds large enough to accommodate it.