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 > > > > http://www.daimi.au.dk/~sandmann/filewrite.patch > > 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