2007/10/22, Kevan Benson <kbenson@xxxxxxxxxxxxxxx>: > > Vincent Régnard wrote: > > Using this latter script reveals that locking is working fine :)). Using > > my program properly also works. I was actually removing the lock file > > when it was locked by another instance ! So my programm was misbehaving > > after that. But the question is "why is it possible to remove a file > > when it is locked?". I can imagine the answer is that system call is not > > the same. Should'nt glusterfs translator forbid or delay unlink() on a > > file when it knows a file is locked ? fcntl or flock based locks are on file content and not on the namespace. unlink() is a namespace operation and no locks are supported by any standard (yet) on the filesystem namespace. This is because even when the file is unlinked (which is actually 'removing a directory entry'), the "actual file" may still be reachable via other hardlinks or open file descriptors. So it does not make sense to forbit unlink()s. avati -- It always takes longer than you expect, even when you take into account Hofstadter's Law. -- Hofstadter's Law
