rjk@sawmill.UUCP (Richard Kuhns) (05/17/89)
In an earlier article, I asked for a portable way to truncate (to size 0) an open file, in the following situation: open the file (for writing); try to lock the file exclusively; if (I can't) tell user someone else is running this program; exit; endif truncate the file (size 0); <--- how do I do this? start writing; I received several responses (which I greatly appreciate), which basically said the same thing -- truncate it by open(2)ing it a second time with the O_TRUNC flag set, and then close the excess file descriptor. This works fine (and is the method I'm currently using), with the following proviso: Don't close(2) the second file descriptor! If you close *either* file descriptor, the lock goes away. At least, it does on a 3B1 running 3.51 -- is this behaviour standard? For this particular application the extra baggage hasn't been a problem, but with several database applications we're running awfully close to the edge (18 active file descriptors), and I can't afford to waste one if there's a way around it. So now, I have a slight variation of my original question: Does anyone have a portable way to truncate (to size 0) an open file, which both maintains an existing lock on the file and doesn't waste a file descriptor? Once again, Thanks in Advance... Rich Kuhns pur-phy!sawmill!rjk
kemnitz@mitisft.Convergent.COM (Gregory Kemnitz) (05/19/89)
In article <269@sawmill.UUCP>, rjk@sawmill.UUCP (Richard Kuhns) writes: < < [stuff deleted] < Don't close(2) the second file descriptor! If you close *either* file < descriptor, the lock goes away. At least, it does on a 3B1 running 3.51 -- < is this behaviour standard? Yes. close() will free any locks on files. < < So now, I have a slight variation of my original question: Does anyone < have a portable way to truncate (to size 0) an open file, which both < maintains an existing lock on the file and doesn't waste a file < descriptor? < No. There is not. Only hope: there is a truncate() and ftruncate() call in POSIX, so there will be one in Sys V.4. -- ----------------------------------+-------------------------------------- Greg Kemnitz | "He who does not understand baseball kemnitz@Convergent.COM | will never understand America" | --Tocqueville
guy@auspex.auspex.com (Guy Harris) (05/20/89)
>No. There is not. Only hope: there is a truncate() and ftruncate() call >in POSIX, so there will be one in Sys V.4. Well, the conclusion ("there will be [f]truncate in S5R4") is, as far as I know, true, but it has nothing to do with the premise: 1) if by POSIX you mean 1003.1, neither "truncate" nor "ftruncate" appear as specified functions - period; 2) if by POSIX you mean some under-development 1003.N, they haven't been ratified (or whatever it is you do to stamp a standard Property of the Zoo) yet, so AT&T isn't *obliged* by those standards to provide it.