Implementing the Inode class

[JacobNickerson]

An inode stores information like:

• File Size
• File Type
• Owner
• Group
• Permissions
• Timestamps
• Pointer to data block
• Links

While implementing the Inode class, it's important how we think about implementing an inode in TBF. I suggest that we maintain a standard layout where say, the first 0-8 bit correspond to one thing, so on and so forth. In our current implementation, each inode is 256 bytes.

[JacobNickerson]

I suggest that we use the following standardized format, I'm open to ideas though because I'm deciding most of this somewhat arbitrarily ( i looked up typical values but did not think more on it than that) (ie please give feedback ;) ):

Data	Size	Offset
File Type	1 Bytes	0 Bytes
Permissions	1 Bytes	1 Bytes
User ID	4 Byte	2 Bytes
Group ID	4 Bytes	6 Bytes
Number of Links	4 Bytes	10 Bytes
Creation Time Stamp	8 Bytes	14 Bytes
Modification Time Stamp	8 Bytes	22 Bytes
Access Time Stamp	8 Bytes	30 Bytes
Pointers to Data Block**	8 Bytes * 12	38 Bytes

** does this depend on the total file size of the file system? I guess you could say each pointer is 8 bytes because we're unlikely to have more than 2^64 - 1 blocks (but never say never!)

Typically, a UNIX system uses 12 direct pointers to a file's data blocks. For our use case, it's unlikely for a file to exceed even a single block, but it might be good to implement this nonetheless. From here, reading about inodes talks about indirect pointers, where an indirect pointer points to a block that contains additional pointers. Not sure if we will implement these as they are typically used when you get very large file sizes.

[JacobNickerson]

Following this scheme, we're left with 122 bytes, not sure what to do with these, aside from the indirect pointers

[cbloodsworth]

This looks very good, yes. We will probably want to have a documentation page on the GitHub to keep track of these things. I'd like to use the "Wiki" for that.

[cbloodsworth]

I suggest that we use the following standardized format, I'm open to ideas though because I'm deciding most of this somewhat arbitrarily ( i looked up typical values but did not think more on it than that) (ie please give feedback ;) ): Data Size Offset File Type 1 Bytes 0 Bytes Permissions 1 Bytes 1 Bytes User ID 4 Byte 2 Bytes Group ID 4 Bytes 6 Bytes Number of Links 4 Bytes 10 Bytes Creation Time Stamp 8 Bytes 14 Bytes Modification Time Stamp 8 Bytes 22 Bytes Access Time Stamp 8 Bytes 30 Bytes Pointers to Data Block* 8 Bytes 12 38 Bytes

** does this depend on the total file size of the file system? I guess you could say each pointer is 8 bytes because we're unlikely to have more than 2^64 - 1 blocks (but never say never!)

Typically, a UNIX system uses 12 direct pointers to a file's data blocks. For our use case, it's unlikely for a file to exceed even a single block, but it might be good to implement this nonetheless. From here, reading about inodes talks about indirect pointers, where an indirect pointer points to a block that contains additional pointers. Not sure if we will implement these as they are typically used when you get very large file sizes.

We could also consider having a field for file size in bytes. 8 bytes, or a long, should be enough for this.