On Tue, Mar 08, 2005 at 06:31:30PM -0600, Federico Mena Quintero wrote:
> On Tue, 2005-03-08 at 20:49 +0100, Soeren Sandmann wrote:
> > I have put up a new patch at
> >
> >http://www.daimi.au.dk/~sandmann/filewrite2.patch
> >
> > that should take care of most of the comments:
> >
> > -
Thus spake Soeren Sandmann:
> Soeren Sandmann <[EMAIL PROTECTED]> writes:
>
> > but then there is a race condition with another thread setting
> > umask. This can be avoided by doing it in a separate process:
...
> > Is there a simpler way to do this?
>
> If there is, I don't know it. I have pu
[EMAIL PROTECTED] (Morten Welinder) writes:
> 1. It is hideously expensive.
This is already a fairly expensive function. And fork() is really not
that bad. My system can fork more than 20 times per second. If
you need to write tons of small files quickly, you should (a) not use
this function
Tor Lillqvist <[EMAIL PROTECTED]> writes:
> Soeren Sandmann writes:
> > The patch does use fchmod(). Are there systems we care about where
> > fchmod() is not available?
>
> Win32... No such thing in the C library. As far as I know, there isn't
> even anything in the underlying Win32 API that w
Soeren Sandmann writes:
> The patch does use fchmod(). Are there systems we care about where
> fchmod() is not available?
Win32... No such thing in the C library. As far as I know, there isn't
even anything in the underlying Win32 API that would enable setting
the permissions for a file based ju
Ack, you did use fchmod, sorry.
Two things regarding the fork approach:
1. It is hideously expensive.
2. It is quite difficult to get right in a library.
Consider: you fork, the child does its thing and exits,
a signal handler you didn't know about waits on the child,
and you call waitpid.
If
[EMAIL PROTECTED] (Morten Welinder) writes:
> fchmod if available?
The patch does use fchmod(). Are there systems we care about where
fchmod() is not available?
> I don't think we care about the permissions being the same as the target
> file's while the file is being created. In fact, mig
fchmod if available?
I don't think we care about the permissions being the same as the target
file's while the file is being created. In fact, might be preferred.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.o
Soeren Sandmann <[EMAIL PROTECTED]> writes:
> I think this is a serious problem. The file should be created with the
> umask permissions. You can do this:
>
> #ifndef G_OS_WIN32
> {
>mode_t mode = umask (0);
>umask (mode);
>
>chmod (filename, mode);
> }
> #endif
>
> but then there
"Alexis S. L. Carvalho" <[EMAIL PROTECTED]> writes:
> > +static gchar *
> > +write_to_temp_file (const gchar *contents,
> > + gsize length,
>
>
> gssize to be consistent with g_file_replace?
>
I have changed it, but I don't see why it
matters. write_to_temp_file() is not called w
On Tue, 2005-03-08 at 20:49 +0100, Soeren Sandmann wrote:
> I have put up a new patch at
>
>http://www.daimi.au.dk/~sandmann/filewrite2.patch
>
> that should take care of most of the comments:
>
> - Function is now called g_file_replace(). (I think
> g_file_replace_contents() suggest
Thus spake Soeren Sandmann:
> I have put up a new patch at
>
>http://www.daimi.au.dk/~sandmann/filewrite2.patch
> +
> +static gchar *
> +write_to_temp_file (const gchar *contents,
> + gsize length,
gssize to be consistent with g_file_replace?
> +
> + tmp_name = g_
comments:
> >
> > - Function is now called g_file_replace(). (I think
> > g_file_replace_contents() suggests that permissions etc. are
> > preserved).
I think we've lost having a name that says "what the function is for".
g_file_write() is a better
On Tue, 2005-03-08 at 20:49 +0100, Soeren Sandmann wrote:
> I have put up a new patch at
>
>http://www.daimi.au.dk/~sandmann/filewrite2.patch
>
> that should take care of most of the comments:
>
> - Function is now called g_file_replace(). (I think
> g_file_replace_contents() suggest
I have put up a new patch at
http://www.daimi.au.dk/~sandmann/filewrite2.patch
that should take care of most of the comments:
- Function is now called g_file_replace(). (I think
g_file_replace_contents() suggests that permissions etc. are
preserved).
- Documentation mentions that t
Don't expect rename to delete the target file on Win32. (There goes
the atomicity.) Checking with g_file_test and unlinking is asking
for a race condition and lost target file in some circumstances.
On unix this type of write will interact in interesting ways with
hardlinks, permissions, file o
Alexis S. L. Carvalho writes:
> Also, will Windows et al handle dot-files correctly?
Initial dot file names are no problem in Windows. (For some reason,
Windows Explorer doesn't let you create such files/folders
interactively, but it let's you otherwise manipulate them if they have
been created b
, so close the filedescriptor */
stale comment
> +
> + retval = g_strdup (tmp_name);
> +
> + out:
> + if (fd != -1)
> +close (fd);
> + g_free (tmp_name);
> + g_free (display_name);
> +
> + return retval;
> +}
Maybe replace the "g_strdup (tmp_name)&qu
On Mon, 2005-03-07 at 00:21 +0100, Soeren Sandmann wrote:
> 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.
>
On UNIX anyway I don't think you need the unlink(), rename() will
overwr
On Mon, 2005-03-07 at 08:51 -0500, muppet wrote:
> On Mar 6, 2005, at 6:21 PM, Soeren Sandmann wrote:
>
> > http://www.daimi.au.dk/~sandmann/filewrite.patch
>
> > + * Writes all of @contents to a file named @filename, with good error
> > checking. If
> > + * a file called @filename already exist
e 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.
I've seen o
On Mar 6, 2005, at 6:21 PM, Soeren Sandmann wrote:
http://www.daimi.au.dk/~sandmann/filewrite.patch
+ * Writes all of @contents to a file named @filename, with good error
checking. If
+ * a file called @filename already exists it will be overwritten.
It may be worth noting in the docs that the fu
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 wr
k.
>
> 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 wr
ose file '%s': fclose() failed: %s"),
+ display_name,
+ g_strerror (errno));
+
+ goto out;
+}
+
+ retval = g_strdup (tmp_name);
+
+ out:
+ if (fd != -1)
+close (fd);
+ g_free (tmp_name);
+ g_free (display_name);
+
+ return retval;
+}
+
+/**
+ * g_file_write
Robert Ögren <[EMAIL PROTECTED]> writes:
> - Why not use g_fopen (and drop the g_utf8_to_utf16 thing)? This makes it
> more likely to work well on Windows
>
> - Shouldn't you free normalized_filename and display_filename also when
> the function completes successfully?
Yeah, both good points
On Sun, 2005-03-06 at 21:38 +0100, Soeren Sandmann wrote:
> Is it useful to add g_file_write() to complement
> g_file_get_contents()? It seems a feature many applications could use.
>
Should it do the atomic write thing? (write to a temporary file
alongside the new file, then rename
On Sun, 6 Mar 2005, Soeren Sandmann wrote:
> Is it useful to add g_file_write() to complement
> g_file_get_contents()? It seems a feature many applications could use.
>
> Patch attached (not tested on Windows). It is also available at
>
>http://www.daimi.au.dk/~sandmann/fil
Is it useful to add g_file_write() to complement
g_file_get_contents()? It seems a feature many applications could use.
Patch attached (not tested on Windows). It is also available at
http://www.daimi.au.dk/~sandmann/filewrite.patch
Søren
Index: gfileutils.c
29 matches
Mail list logo
