[boost] Re: Re: Serialization and tmpnam

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-07-20 07:12:01

Jonathan Wakely wrote:

>> There is no way to atomically create a directory. The only atomic
>> filesystem modification is file creation; this property of filesystems on
>> UNIX/POSIX is widely known and has numerous consequences, including the
>> use of lock files to implement persistent advisory locking, and many
>> convolutions involving secure temporary files.
> 
> Yes, I appreciate that, but if the temp files are created in an existing
> directory (say, part of the CVS sandbox) that has the right permissions
> then there's no need to create a directory, so it's not a problem that
> you can't do so safely.
> 
> "Doctor, doctor, when I create directories it causes a race condition."
> "Don't create directories then"

Actually, I'm not sure what it means to atomically create a directory. Yes,
if you check for directory existence and then try to create it, some other
process might sneak in and create the directory before you. This is the
same problem as with files. But, for files, when you try to create already
existing files, you might delete all content. For directory creation, the
call will just fail. The docs (mkdir manpage, and also the "Single UNIX
specification"), say:

  ERRORS

  EEXIST 
  pathname already exists (not necessarily as a directory). This includes  
  the case where pathname is a symbolic link, dangling or not. 

(BTW, some time ago I even argued that fs::create_directory should ignore
EEXIST error).

And since the directory create will have your permissions only, I don't know
where the problems is. Besides, it's always possible to use /tmp

>> The only secure way to use temporary files is to have a function which
>> securely and atomically creates and opens one and returns you the file
>> descriptor, and to use that file descriptor (and not the path/name to the
>> new temporary file) to access the file thereafter.
>> 
>> This causes problems because there is no standard way to convert a file
>> descriptor to an iostream (although most vendors have vendor extensions
>> that allow you to do so). This alone should probably be abstracted away
>> in boost, as it's a common request, but even if it isn't, it has to be
>> used for secure temporary files. There is no way around it.
> 
> This is a _very_ good candidate for Boost, as everyone has to rely on
> incompatible vendor extensions. I'd love to have time to work on it.

Me too :-(

- Volodya