On Fri, 10 Jun 2005, Patrick Lam wrote: > Jeremy C. Reed wrote: > > Please make sure this doesn't have race conditions when using /tmp or > > TMPDIR. > > > > Maybe use O_EXCL (with open(2)) when creating, but that may not be good > > enough for some network-based filesystems. > > > > And don't use 666 for creating the file. If I overlooked or misunderstood > > something, please let us know. > > I will use 600 rather than 666. Since this file is just hanging around > anyway, it seems to be insufficient to avoid race conditions. I think > that if I could create a checksum (e.g. CRC32) of the expected state, as > written, and verified the checksum before read, that ought to be > sufficient; what do you think? You better use O_EXCL anyway. Just in case two copies of fc-mmap happen to run in parallel, or something. How is fc-mmap supposed to be called BTW? Why not dump the cache in the library if it doesn't exist? > Alan Coopersmith wrote: > > But only if fonts.mmap is platform independent. Many places > > use home directories NFS shared across different types of machines. > > (big & little endian, 32 & 64 bit, etc.) > > It's hard to imagine how one could possibly make fonts.mmap platform > independent. However, I have included the output of uname's sysname and > machine fields in the filename to prevent horrible outcomes, and as an > extra check, I verify endianness by writing 0x12345678 to the file and > reading it again. You should be fine as long as you do it in /tmp. > pat --behdad http://behdad.org/
