> The issues with mktemp() are long well understood and > I'm pretty sure every vendor has fixed this in anything resembling a > currently supported OS.
The man pages I linked to indicate different levels of progress. Anyway, yeah, those who view it as no more than a string generator holding some degree of randomness will be fine. Those who view it as gold and don't do proper diligence with their open(), won't. > http://marc.info/?l=mutt-dev&m=128900518711082 The link method would allow for more flexibility in naming [fuller prefix, suffix, etc] within the same dir. Only thought I'd add would be - Will having two entries during the duration the former exists, or after a crash, give rise to user question, cleanup, etc. - How are other apps, even other instances of mutt going to treat either file, such as two entries in a Maildir might. If the purpose is to have a [pre/suf]fix file that is not ephemeral, local generation might avoid those. I don't recall the requirement other than something about treating extensions as keys to content or file sorting or something. > I'd be reasonably happy to take some time to write > had to pull some teeth to get committed a couple of patches related to There was something today about >2GiB mboxes, I've seen those :) I'm mostly a mutt user. I think there was a thread here about development. As with any OSS, whiteboard a survey of outstanding patches, stalled feature requests etc and try to process through them in order as a team. If that doesn't produce good result for some fraction of the community, throw it up on github with why and see what develops there. No big deal. Not seeing a release in over 2.5 years makes me leery... mutt's good, but not that good, always some bits to improve, and systems always tick forward. Don't let it become the next [abandon/fist]ware. I'd fork it myself before that :) [I'm unable to thread this with the development thread since I deleted that mail, apology for that. Try to thread it there if there's more to add.]
