Mounting fs with mandatory locking

[davidbatelu]

I really need to know how to mount my fs(ext2) with the MS_MANDLOCK flag set.
i have already changed the user group bit as well as the execution bit for the file in consideration and have mounted the system by using the rw,mand option.
but whn i tried the IS_MANDLOCK fuction on the inode of this file in my system call it returned zero(failed)......
can anyone tell me some solution that would allow me to use mandatory locking on my fs?

[bwkaz]

1) I believe you need to have all execute bits turned off on the file (plus set-group-id turned on); I'm not sure if you actually have it set up this way or not.

2) There is no "IS_MANDLOCK function". There's nothing even remotely similar to it. The interface to locking and unlocking files subject to mandatory locking is fcntl(), which is the exact same interface as you use with files subject to advisory locking. If fcntl() is failing, you will want to call perror() to print out a description of the most-recent error number (i.e. the contents of errno); you can then look up this description to figure out what the problem is. (For instance, other processes may already have the file opened in a manner incompatible with your lock, so your lock fails. According to the fcntl manpage, the errno value that you get in that case is either EACCES ("Permission denied") or EAGAIN ("Try again").)

[davidbatelu]

ill try setting all the execute bit off and tell u wht happens...
but abt the IS_MANDLOCK function... actually its a macro found in the fs.h file @ line 171(linux 2.6.20) ... if u want to see wht it looks like chk this link
http://lxr.linux.no/linux+v2.6.20/include/linux/fs.h#L171
i believe that it shld work provided mandatory locking has been enabled

[bwkaz]

Um, no, that's not actually a function you can use. That's a #define that's internal to the kernel. Userspace programs cannot call it or use it, mostly because userspace programs don't have access to the kernel's inode structure. (But even if they did, relying on specific implementation details like the bits in the structure is a REALLY BAD idea. Those bits can move around or change at any time, without warning from the kernel. The only thing that's guaranteed to never change is the interface to userspace -- the kernel function that glibc calls into when you call fcntl.)

(And in case you're wondering: you can't include kernel headers in a userspace program, either. That's explicitly unsupported by the kernel developers. You're supposed to use the interface headers that glibc was compiled against, because your program has to talk through glibc to get to the kernel.)