iluvu@homxc.ATT.COM (S.RAVIKUMAR) (04/13/89)
I tried to restrict access to a shared resource between processes using the unix system call "lockf". The piece of code is as follows: fd = open(FILENAME, O_CREAT, 0666); lockf(fd, F_LOCK, (long)0); "lockf" always returns with an error and errno is set to "Bad file descriptor". Any help or suggestions are welcome. Thanks. --ravi skumar@hocus.att.com
kucharsk@uts.amdahl.com (William Kucharski) (04/13/89)
Calls to lockf(3C) must be made with a file descriptor opened to either
O_WRONLY or O_RDWR modes.
So, change your code to read:
fd = open(FILENAME, O_CREAT | O_RDWR, 0666);
lockf(fd, F_LOCK, (long)0);
Everything will work just fine.
--
William Kucharski
ARPA: kucharsk@uts.amdahl.com
UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk
Disclaimer: The opinions expressed above are my own, and may not agree with
those of any other sentient being, not to mention those of my
employer. So there.rkl1@hound.UUCP (K.LAUX) (04/13/89)
In article <6307@homxc.ATT.COM>, iluvu@homxc.ATT.COM (S.RAVIKUMAR) writes: | I tried to restrict access to a shared resource between | processes using the unix system call "lockf". The piece of code | is as follows: | | fd = open(FILENAME, O_CREAT, 0666); | lockf(fd, F_LOCK, (long)0); | | "lockf" always returns with an error and errno is set to "Bad | file descriptor". Any help or suggestions are welcome. Sounds like the open call is returning an error. You should check for this before issuing the lockf call. Also, after opening a file with O_CREAT, I close the file, then reopen it with another open call, because O_CREAT will only let you write to the file, and I usually need read/write permission. --rkl
kremer@cs.odu.edu (Lloyd Kremer) (04/14/89)
In article <3012@hound.UUCP> rkl1@hound.UUCP (K.LAUX) writes: >after opening a file with O_CREAT, I close the file, then >reopen it with another open call, because O_CREAT will only let you >write to the file, and I usually need read/write permission. My experience has been that you can't assume any particular read/write capability from a file opened with O_CREAT only. O_CREAT alone will often simply create the file (take out a directory entry under that name). To be portable, O_CREAT should always be combined with exactly one of O_RDONLY, O_WRONLY, or O_RDWR, according to what you wish to do with the file. O_TRUNC or O_EXCL are often combined with O_CREAT, also. Lloyd Kremer Brooks Financial Systems {uunet,sun,...}!xanth!brooks!lloyd
guy@auspex.auspex.com (Guy Harris) (04/18/89)
> Also, after opening a file with O_CREAT, I close the file, then >reopen it with another open call, because O_CREAT will only let you >write to the file, and I usually need read/write permission. On all UNIX systems (note the magic word "unix" in the subject line) I know of that support O_CREAT, opening with O_CREAT specified by itself only lets you *read* from the file, because it's equivalent to opening with O_CREAT|O_RDONLY, since O_RDONLY is 0 - before O_RDONLY and company, and the 3-argument "open", existed, the second argument was officially defined as 0 for read-only, 1 for write-only, and 2 for read/write. That was, quite likely, the source of the original problem, since "lockf" grabs a write lock and thus requires that you have the file open for writing. On a non-UNIX implementation of "open", it may be the case that O_CREAT by itself only let you write to the file, but we appear to be talking about UNIX here.... Opening with O_CREAT|O_RDWR will let you read from or write to the file. Now, if you open the file by using the "creat" system call, the resulting file descriptor will only let you write to the file; "creat" is equivalent to "open" with O_CREAT|O_TRUNC|O_WRONLY specified. One reason to prefer the 3-argument "open" is that it doesn't force you to have a write-only file descriptor as the result of a call that creates a file....