<<< Date Index >>>     <<< Thread Index >>>

Re: mutt_adv_mktemp() ?



On Wednesday, October  4 at 02:49 PM, quoth Rocco Rutte:
Without any reading, I'm not sure if it's a good idea to rename() a file which is already open.

As long as it stays on the same filesystem (which, if all you're doing is adding a suffix, should not cause the filesystem to change), it should be just fine. File descriptors stay with the inode, not the filename. That's why you can do fun things like delete open files, and have them continue to work until you close them.

But you still can have races between the test for the existence of the new file and the actual rename and thus loose data.

Wha? I'm not sure what you're saying here. Yes, the rename doesn't test that another file of the same name doesn't already exist, but the same problem already exists for using mktemp. Which, I suppose, is really no better than the current mktemp() method, now that I think about it. I guess all I was really saying there is that not being able to specify suffixes is NOT a good reason to avoid mkstemp(). A better reason would be that because of suffixes, mkstemp() is no better than mktemp().

On the other hand, mkstemps() would solve the problem, at least for the OS's that support it, i.e. all modern Unixes (it works on Tru64 Unix, Solaris, FreeBSD, OpenBSD, NetBSD, MacOS X, OpenSolaris, Solaris, and Linux). Where it falls down is on HP-UX and older Solaris boxes (that I know of). A portable implementation is included in libiberty, if someone's feeling ambitious enough to add it to mutt.

~Kyle
--
In wine there is wisdom, in beer there is strength, in water there is bacteria.
                                                    -- German proverb

Attachment: pgpEsBeWEwVuy.pgp
Description: PGP signature