You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Ph. Marek" <ph...@bmlv.gv.at> on 2004/12/23 06:58:51 UTC

Q regarding svn_io_open_unique_file and persistent files

Hello everybody!

I have a question: How shall svn_io_open_unique_file be used, if the 
destination file should stay in the filesystem (and already exists)?
- shall the file be opened with delete_on_close=TRUE, and renamed
  before it is closed?
  -> Failures on close lead to data loss, as possibly not everything
     could be written.
     (or is that avoided by the use of svn_io_file_flush_to_disk()?)
  -> It is a little bit "wrong" to unlink() a file which isn't valid 
     any more (as it is renamed on close())
- shall the file be opened with delete_on_close=FALSE?
  -> If an SVN_ERR() cancels this function, the temporary file is left and 
     takes space in the filesystem.
- shall it be opened with delete_on_close=TRUE, and before the
  svn_io_file_close() the flag is cleared?
 file->flags &= ~APR_DELONCLOSE;


Opinions, hints?

Thank you!


Regards,

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Q regarding svn_io_open_unique_file and persistent files

Posted by Erik Huelsmann <eh...@gmail.com>.
On Thu, 23 Dec 2004 07:58:51 +0100, Ph. Marek <ph...@bmlv.gv.at> wrote:
> Hello everybody!
> 
> I have a question: How shall svn_io_open_unique_file be used, if the
> destination file should stay in the filesystem (and already exists)?
> - shall the file be opened with delete_on_close=TRUE, and renamed
>   before it is closed?
>   -> Failures on close lead to data loss, as possibly not everything
>      could be written.
>      (or is that avoided by the use of svn_io_file_flush_to_disk()?)
>   -> It is a little bit "wrong" to unlink() a file which isn't valid
>      any more (as it is renamed on close())
> - shall the file be opened with delete_on_close=FALSE?
>   -> If an SVN_ERR() cancels this function, the temporary file is left and
>      takes space in the filesystem.
> - shall it be opened with delete_on_close=TRUE, and before the
>   svn_io_file_close() the flag is cleared?
>  file->flags &= ~APR_DELONCLOSE;
> 
> Opinions, hints?

Well, the file->flags &= .. ;

won't work but on unix: on Win32 there is an api which signals the
removal to requirement to the OS. It can't be reset.

To understand the cleaning system, you have to understand about pools.
As memory, other resources can be tied to pools too. Files get closed
and cleaned if they were not closed before the pool gets cleaned or
destroyed. Pools get destroyed if their parent gets destroyed, so that
upon errors files are cleaned up.

If you specify delete_on_close, as the name suggests, the file gets
deleted when closed, even if you rename the file before it gets closed
(at least on some OSes).

bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Q regarding svn_io_open_unique_file and persistent files

Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2004-12-23 at 01:58, Ph. Marek wrote:
> - shall the file be opened with delete_on_close=FALSE?
>   -> If an SVN_ERR() cancels this function, the temporary file is left and 
>      takes space in the filesystem.

You can set a pool cleanup handler which removes the file, and then
cancel the cleanup handler when the file is ready to be preserved.

There are examples of this in libsvn_wc/repos_diff.c and
libsvn_wc/diff.c; search for apr_pool_cleanup_kill.  It's a fair amount
of code; perhaps it should be abstracted out somewhere, either in
Subversion or in APR.  (It feels a little too generic for Subversion,
but a little too fiddly for APR, so I don't have a strong opinion.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org