[Stage 23] Possible bug in delete system call (interrupt)

[NITHIN R]

Dear community,

I noticed that in the implementation of delete system call, after acquiring lock on the file, we are not checking for two cases:

1. Case where the file gets deleted (by some other processes) when waiting for the lock. However, not considering this case doesn't seem to cause any errors or unexpected behaviors. (This case is considered inside acquire_inode() function in resource manager, but not in delete system call). 
2. Case where the file gets deleted and its inode index gets occupied by another file when waiting for the lock. (Although, this case is mentioned here in open() function of file manager, it hasn't been implemented in open() function).

Checking the return value of acquire_inode() function and stopping the execution of delete system call if the return value is -1 should fix the first case.

I can't come up with a fix for the second case, when the new file has the same name as the old one.

[Murali Krishnan]

Nice catch.   But is  the second one actually a bug?   If you have permissions to delete a file at the point you have acquired the inode, you are entitled to do it  (whether or not the file has changed).

One possible solution is to pass the file name to the acquire function and check the name before locking the inode.  However, if the new file is created by the same name, then the problem will persist.  

Certain integrity requirements are hard to do even at the kernel level, and will have to be handled at the application programmer.  That is why the design of co-operating concurrent applications turns out to be pretty tricky. 

--
You received this message because you are subscribed to the Google Groups "XOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xos-users+...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/xos-users/2a47204c-e94f-470f-8bfa-0afcc43ea465n%40googlegroups.com.