Hey guys!!!
I know these simulations are too much but....
still another one and I am havin some problems with that///
I have to create a file system simulation that has to understand these commands:
cr a - create a new file named a, size ==0;
rm a - remove file a
op a - open file a
cl a - close file a
rd a - read file a
wr a - write file a
cp a b - copy file a to file b

I have to use:
DIRECTORY IMPLEMENTATITON
LINEAR LIST
ALLOCATION METHODS
CONTIGUOUS ALLOCATION
LINKED ALLOCATION(FAT)
FREE - SPACE MANAGEMENT
FREE-SPACE LIST
PROTECTION AND SECURITY

I HAVE TO USE AN ARRAY OF BYTES

P.S PLEASE GIVE ME SOME IDEA... I KNOW HOW TO DO SOME OF THE STAFF BUT I AM NOT SURE IF THIS IS THE RIGHT WAY TO APPROACH IT
LIKE INSTEAD OF ARRAY OF BYTES I WILL CREATE A BYTE BUFFER TO ALLOCATE THE SPACE...
BUT I HAVE NO IDEA HOW TO ALLOCATE THE SPACE ONCE THE FILE IS CREATED!!!!

Dani AI

Generated

For : the cleanest way to meet the brief is to treat the byte array as a raw "disk" and build small layers on top — a block layer, a metadata (inode/directory) layer, an allocation layer (contiguous and linked/FAT implementations), and an open-file table with per-handle state. That keeps the Java runtime out of the picture (so 's hint about java.io.File can be ignored for the simulation requirement) while making each responsibility testable and pluggable.

Core pieces and a few concrete snippets:

  • Represent the disk and blocks:
    
    final int BLOCK_SIZE = 512;
    byte[] disk = new byte[BLOCK_SIZE * NUM_BLOCKS];

int offsetFor(int blockIndex) { return blockIndex * BLOCK_SIZE; }

void writeBlock(int blockIndex, byte[] src) {
System.arraycopy(src, 0, disk, offsetFor(blockIndex), Math.min(src.length, BLOCK_SIZE));
}


- Free-space: use a bitmap for quick allocation and an auxiliary free-list of ranges for contiguous allocation. Example first-fit finder for contiguous runs:

int findContiguous(boolean[] free, int needed) {
int run = 0;
for (int i = 0; i < free.length; i++) {
run = free[i] ? run + 1 : 0;
if (run == needed) return i - needed + 1;
}
return -1;
}



- FAT/linked allocation: keep an int[] fat where fat[i] == -1 means free, otherwise fat[i] holds the next block index (or -2 for EOF). Directory entries store metadata (name, size, startBlock or inode id), and the open-file table stores current offset, mode, and a reference count.

Protection, security and correctness: store simple permission bits in the inode and enforce them in open/read/write paths; use synchronization around shared structures (free bitmap, FAT, directory) to avoid races; test with tiny disks and extreme cases (zero-size files, full disk, fragmentation, repeated creates/removes). Mention of BoxedApp or OS file APIs (@JAGjug, @MastAvalons) is useful for other problems, but for this homework-style simulation the in-memory byte array approach is the simplest and most verifiable.

Recommended Answers

All 6 Replies

Open up a text editor and get started.

Then I tried to emulate file system I had no idea how to do that. BoxedApp SDK helped very much.
(But that project I wrote in C++:) )

commented: 3 year old thread. -2

Then I tried to emulate file system I had no idea how to do that. BoxedApp SDK helped very much.
(But that project I wrote in C++:) )

And I am sure the guy has already solved his problem 3 years ago, Talk about speedy replies !!!!

Oh ****, what a waste of time. I didn't even realize that this noob had upped an ancient thread.

Then I tried to emulate file system I had no idea how to do that. BoxedApp SDK helped very much.
(But that project I wrote in C++:) )

Your help in time.:cool: :idea:
excellent sdk!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.