mills%cc.uofm.cdn%ubc.csnet@RELAY.CS.NET (Gary Mills) (10/24/87)
Has anyone figured out how to perform the BSD functions ``fsync()'' and ``ftruncate()'' in System V? I may be able to do without ``fsync()'', but ``ftruncate()'' would be very nice to have in the software I am porting. -Gary Mills- <mills@cc.uofm.cdn> -University of Manitoba- -Winnipeg, Canada-
guy%gorodish@Sun.COM (Guy Harris) (10/24/87)
> Has anyone figured out how to perform the BSD functions ``fsync()'' > and ``ftruncate()'' in System V? You can get the same general effect as "fsync" in some S5 implementations by using "fcntl" to turn the O_SYNC flag on for a file descriptor; this flag causes all writes to that descriptor to be done synchronously. Unless you're truncating a file to zero length, you can't do "ftruncate()" except by making a copy of the file up to the new length, doing a "creat" or "open" with O_TRUNC to truncate the original file to zero length, and then copying the truncated copy on top of the original file. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
jimr@hcrvx2.UUCP (Jim Robinson) (10/27/87)
In article <31892@sun.uucp> guy@gorodish.UUCP writes: >> Has anyone figured out how to perform the BSD functions ``fsync()'' >> and ``ftruncate()'' in System V? > >You can get the same general effect as "fsync" in some S5 implementations by >using "fcntl" to turn the O_SYNC flag on for a file descriptor; this flag >causes all writes to that descriptor to be done synchronously. This feature does not seem to be documented for SVR2 (or SVR2V2), however, the supporting kernel code does appear to be there. Is this another instance of AT&T forgetting to document a feature, or am I not looking in the right place, or is there another explanation? PS The documentation I am referring to is the standard AT&T "Programmer Reference Manual" and the "Version 2 Supplement" for VAX 11/780 - 11/750 Processors. J.B. Robinson
chris@nrcvax.UUCP (10/27/87)
guy%gorodish@Sun.COM (Guy Harris) says: >> Has anyone figured out how to perform the BSD functions ``fsync()'' >> and ``ftruncate()'' in System V? > >Unless you're truncating a file to zero length, you can't do "ftruncate()" >except by making a copy of the file up to the new length, doing a "creat" or >"open" with O_TRUNC to truncate the original file to zero length, and then >copying the truncated copy on top of the original file. This will give you truncate(), not ftruncate(), which requires a file descriptor, and if that's all you have, then you're in trouble. -- Chris Grevstad cit-vax!elroy!nrcvax!chris@rutgers.edu hplabs!sdcrdcf!psivax!nrcvax!chris ihnp4!nrcvax!chris Where subtlety fails us we must simply make do with cream pies.
dbg@u1100a.UUCP (D B Grooms) (10/28/87)
> Has anyone figured out how to perform the BSD functions ``fsync()'' > and ``ftruncate()'' in System V? > >>... >> >>Unless you're truncating a file to zero length, you can't do "ftruncate()" >>except by making a copy of the file up to the new length, doing a "creat" or >>"open" with O_TRUNC to truncate the original file to zero length, and then >>copying the truncated copy on top of the original file. For efficiency, it would be better to "mv" the original file to one with a new name, "creat" the original file, and copy the desired size from the newly named file to the original. This involves only one copy operation instead of two. Dave Grooms Bell Communications Research {ihnp4,bellcore,pyuxww}!u1100a!dbg x x x x x
guy%gorodish@Sun.COM (Guy Harris) (10/28/87)
> For efficiency, it would be better to "mv" the original file to one with a > new name, "creat" the original file, and copy the desired size from the > newly named file to the original. ...after, of course, doing an "fstat" on the original to make sure there's only one link to it. Otherwise, while it's faster than overwriting the original file, it's not equivalent to doing so or to doing an "ftruncate". Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
wescott@sauron.UUCP (10/29/87)
In article <1596@u1100a.UUCP> dbg@u1100a.UUCP (D B Grooms) writes: >> Has anyone figured out how to perform the BSD functions ``fsync()'' >> and ``ftruncate()'' in System V? >>>... making a copy of the file up to the new length, doing a "creat" or >>>"open" with O_TRUNC to truncate the original file to zero length, and then >>>copying the truncated copy on top of the original file. > For efficiency, it would be better to "mv" the original file to one with a > new name, "creat" the original file, and copy the desired size from the > newly named file to the original. This involves only one copy operation > instead of two. This does not take care of links and is not a general solution. Any other name for the original file remains linked to the original inode and is not truncated. -- -Mike Wescott wescott@ncrcae.Columbia.NCR.COM
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/30/87)
In article <1596@u1100a.UUCP> dbg@u1100a.UUCP (D B Grooms) writes:
-For efficiency, it would be better to "mv" the original file to one with a
-new name, "creat" the original file, and copy the desired size from the
-newly named file to the original. This involves only one copy operation
-instead of two.
But it completely scrogs the inode attributes (owner, mode, i-number, etc.).guy%gorodish@Sun.COM (Guy Harris) (11/02/87)
> This feature does not seem to be documented for SVR2 (or SVR2V2), > however, the supporting kernel code does appear to be there. Is this > another instance of AT&T forgetting to document a feature, or am I not > looking in the right place, or is there another explanation? I remember looking at this several years ago and concluding that S5R2 *almost* implemented synchronous I/O for user mode, but that there was one small piece missing. The FSYNC bit was, at the time, used internally for some operations to keep the file system as self-consistent as possible at all times. I think they finished making it usable by applications in some later release (probably S5R3), and documented it then. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com