elliott-beach / project3

http://www-users.cselabs.umn.edu/classes/Fall-2017/csci5103/PROJECT/PROJECT3/project3.pdf
0 stars 0 forks source link

unlink: Check if other processes have open file, free blocks when done #16

Open ghost opened 6 years ago

ghost commented 6 years ago

I used the IndexNode::free() function from your pending pull request in Kernel::close

elliott-beach commented 6 years ago

1) I don't think this works because when I use rm after this change and then fsck, it shows that none of the blocks got freed. 2) There is a conflict that confused me to resolve.

elliott-beach commented 6 years ago

Another thought, why do we need to support multiple programs using the kernel simultaneously? Because the kernel is just a simple C program that you include, that isn't actually possible with the current architecture. It's true I could have thought of that when you mentioned it the first time.

ghost commented 6 years ago

That's a good question. Now that I take a closer look at it, this isn't even possible with the current FileDescriptor structure. In order to tell if the same file is open, not just an inode, the FileDescriptor would need to contain the path name of the file. Otherwise we could only compare inodes which is not what unlink is supposed to do.

ghost commented 6 years ago

But in order to include the pathname of the file, we would need to change every place where the constructor is called.

elliott-beach commented 6 years ago

Given that it’s a requirement for the project, we can make it happen somehow. FIleDescriptor has a short IndexNodeNumber which we can use.

ghost commented 6 years ago

But the same indexNodeNumber could correspond to 2 different files. Unlink should only apply to filenames not to inodes. It shouldn't delete an inode

elliott-beach commented 6 years ago

We only do the removal stuff when nlinks is decremented to zero. In that case, the inode is 1to1 with the file, so I still think we can use the inode number