Re: g_file_write()

On Mon, 2005-03-07 at 10:10 +0100, Iago Rubio wrote:
> On Mon, 2005-03-07 at 00:21 +0100, Soeren Sandmann wrote:
> > > Should it do the atomic write thing? (write to a temporary file
> > > alongside the new file, then rename() to the final filename)
> > > 
> > > The minus is that you need double the size of the file to write it, but
> > > the plus is that you aren't screwed if you run out of disk space mid-
> > > overwrite.
> > 
> > I think it makes sense to do the atomic write. Here is a new patch
> > that does that. It also uses the g_* versions where appropriate and
> > hopefully doesn't leak.
> > 
> > Patch is attached and also available at 
> > 
> >
> Nice job :)
> I really like to see file write operations on glib, but I don't know if
> the function's name is the best to use.
> It seems that g_file_write should be something like the write()
> function, so you can get an file descriptor with g_fopen() and write to
> it.

  We already have fwrite and fread in libc, which AFAIK are completely
portable.  No need to replicate this in glib just to get a silly g_
prefix <wink/>

> May be g_fwrite() is also needed to diferentiate it from g_file_write
> () ?
> It'll give users the ability to write to the file (descriptor) in the
> same way they used the write() function, so it can be used in loops with
> no need of filling memory to get the whole buffer to write to the file.

  What you're describing sounds like GLib's GIOChannel's.

> The current patch will be memory hungry on really large files, as the
> buffer should be the entire file on memory.

  Then this should be mentioned in the documentation, that's all.  The
API doesn't have to apply to all use cases.

> Just my 2 cents.
> Regards.
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]