On Mon, 15 Nov 2010 08:57:51 +1100
Lex Trotman ele...@gmail.com wrote:
On 11 November 2010 00:27, Nick Treleaven nick.trelea...@btinternet.com
wrote:
On Wed, 10 Nov 2010 10:13:29 +1100
Lex Trotman ele...@gmail.com wrote:
Also, g_file_replace_contents does have a make_backup argument
2010/11/16 Dimitar Zhekov dimitar.zhe...@gmail.com:
On Mon, 15 Nov 2010 08:57:51 +1100
Lex Trotman ele...@gmail.com wrote:
On 11 November 2010 00:27, Nick Treleaven nick.trelea...@btinternet.com
wrote:
On Wed, 10 Nov 2010 10:13:29 +1100
Lex Trotman ele...@gmail.com wrote:
Also,
On 11 November 2010 00:27, Nick Treleaven nick.trelea...@btinternet.com wrote:
On Wed, 10 Nov 2010 10:13:29 +1100
Lex Trotman ele...@gmail.com wrote:
Also, g_file_replace_contents does have a make_backup argument we could
provide an option for. This might handle the disk exhaustion problem.
On 11 November 2010 00:27, Nick Treleaven nick.trelea...@btinternet.com wrote:
On Wed, 10 Nov 2010 10:13:29 +1100
Lex Trotman ele...@gmail.com wrote:
Also, g_file_replace_contents does have a make_backup argument we could
provide an option for. This might handle the disk exhaustion problem.
On Wed, 10 Nov 2010 21:23:18 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
Why fake 0 errno as EIO? g_file_set_contents() doesn't, and *strerror()
returns something for 0, usually Error 0.
GLib says to use g_strerror, which says 'Success', which is confusing.
It is, but
On Wed, 10 Nov 2010 10:13:29 +1100
Lex Trotman ele...@gmail.com wrote:
Also, g_file_replace_contents does have a make_backup argument we could
provide an option for. This might handle the disk exhaustion problem.
To summarise the long thread for you Nick, g_file_replace_contents and
On Wed, 10 Nov 2010 13:25:56 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
But since we don't write the file line-by-line or
something, _why_ do we use buffered I/O in the first place?..
I don't know. But changing implementation often introduces bugs, so
I'm
On Wed, 10 Nov 2010 13:25:56 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Tue, 9 Nov 2010 21:27:07 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
Well, g_file_set_contents() uses buffered I/O, so obviously it's
acceptable too.
Yes, it uses fwrite and then
On Wed, 10 Nov 2010 20:02:53 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
Ah, it sets errno = 0 first, assuming that fwrite() may fail to do so.
I've now committed a fix so that any write failure should be reported
to the user even if errno is 0. Please test.
It won't be 0
On Wed, 10 Nov 2010 18:14:04 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Wed, 10 Nov 2010 20:02:53 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
Why fake 0 errno as EIO? g_file_set_contents() doesn't, and *strerror()
returns something for 0, usually Error 0.
On Tue, 9 Nov 2010 13:33:26 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Sat, 6 Nov 2010 11:33:41 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
I'll write a non-GIO variant first, as a proof of concept.
First, I feel quite reluctant to use non-GLib/GIO functions
On Tue, 9 Nov 2010 18:57:03 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Tue, 9 Nov 2010 20:28:43 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
With binary I/O we have fsync(), which really flushes the data.
Even fflush() and fclose() are not guaranteed to do that.
Hi again Nick,
On 10 November 2010 00:33, Nick Treleaven nick.trelea...@btinternet.com wrote:
On Sat, 6 Nov 2010 11:33:41 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
I'll write a non-GIO variant first, as a proof of concept.
First, I feel quite reluctant to use non-GLib/GIO
On Sun, 7 Nov 2010 13:18:48 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
On Thu, 4 Nov 2010 22:42:04 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
Before we had safe or unsafe file saving. Let's keep that choice,
shall we? I can write the patch, it's only a few lines.
On Thu, 4 Nov 2010 22:42:04 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
On Thu, 4 Nov 2010 17:53:47 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
So it seems that function doesn't handle disk exhaustion safely. (But
this is no worse than before for Geany).
Before
On Sat, 6 Nov 2010 21:31:31 +1100
Lex Trotman ele...@gmail.com wrote:
On 6 November 2010 20:33, Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
1. Open the file for reading and writing.
I'm not sure all non-local filesystems support read/write or they
support it via local caching which
Le 06/11/2010 13:45, Dimitar Zhekov a écrit :
On Sat, 6 Nov 2010 21:31:31 +1100
Lex Trotman ele...@gmail.com wrote:
On 6 November 2010 20:33, Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
If not anything else, we should use non-buffered I/O, with fsync(), and
check the result of close()
On 11/05/2010 08:42 AM, Colomban Wendling wrote:
But from an efficiency point of view its much more work. Probably not
a problem on a local filesystem, but on a remote filesystem it
requires three transfers of the data instead of one, read the old file
and write the backup then write the new
On Fri, 05 Nov 2010 10:57:23 -0700
Jason Oster jason.os...@campnavajo.com wrote:
On 11/05/2010 08:42 AM, Colomban Wendling wrote:
But from an efficiency point of view its much more work. Probably not
a problem on a local filesystem, but on a remote filesystem it
requires three transfers
On Thu, 04 Nov 2010 23:37:28 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 04/11/2010 21:42, Dimitar Zhekov a ecrit :
For more than 20 years now, the only safe save is to write the data
into a temporary file in the same directory, and then rename it over
the target file.
Le 05/11/2010 20:08, Dimitar Zhekov a écrit :
On Thu, 04 Nov 2010 23:37:28 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 04/11/2010 21:42, Dimitar Zhekov a ecrit :
For more than 20 years now, the only safe save is to write the data
into a temporary file in the same
On Fri, 05 Nov 2010 19:50:59 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 05/11/2010 20:08, Dimitar Zhekov a ecrit :
a. Create filename-foo, write data to it, abort and unlink on failure.
[...]
Hey, that's quite clever :) We would then avoid to have to read the
original
Le 05/11/2010 21:33, Dimitar Zhekov a écrit :
On Fri, 05 Nov 2010 19:50:59 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 05/11/2010 20:08, Dimitar Zhekov a ecrit :
a. Create filename-foo, write data to it, abort and unlink on failure.
[...]
Hey, that's quite clever :) We
On 6 November 2010 04:57, Jason Oster jason.os...@campnavajo.com wrote:
On 11/05/2010 08:42 AM, Colomban Wendling wrote:
But from an efficiency point of view its much more work. Probably not
a problem on a local filesystem, but on a remote filesystem it
requires three transfers of the data
On 6 November 2010 10:43, Colomban Wendling lists@herbesfolles.org wrote:
Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
On Thu, 4 Nov 2010 17:53:47 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
So it seems that function doesn't handle disk exhaustion safely. (But
this is no
On Wed, 03 Nov 2010 00:26:00 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 02/11/2010 19:11, Nick Treleaven a écrit :
Hi list,
To workaround bug(s) in GVFS, I've now changed the file saving
implementation for systems with GIO in SVN trunk. See also:
On Tue, 2 Nov 2010 18:11:01 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
To workaround bug(s) in GVFS, I've now changed the file saving
implementation for systems with GIO in SVN trunk. See also:
http://lists.uvena.de/geany-devel/2010-November/003412.html
Please help test
Le 04/11/2010 17:26, Nick Treleaven a écrit :
On Wed, 03 Nov 2010 00:26:00 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 02/11/2010 19:11, Nick Treleaven a écrit :
Hi list,
To workaround bug(s) in GVFS, I've now changed the file saving
implementation for systems with GIO in
On Thu, 4 Nov 2010 20:37:13 +0200
Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
To workaround bug(s) in GVFS, I've now changed the file saving
implementation for systems with GIO in SVN trunk. See also:
http://lists.uvena.de/geany-devel/2010-November/003412.html
Please help test
On Thu, 04 Nov 2010 18:14:17 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Interesting change, let's see what happens now -- this said I don't use
remote files often so I will probably not notice any change...
Actually I should have been clearer - this change affects local
On Thu, 4 Nov 2010 17:53:47 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
So it seems that function doesn't handle disk exhaustion safely. (But
this is no worse than before for Geany).
Before we had safe or unsafe file saving. Let's keep that choice, shall
we? I can write the
Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
On Thu, 4 Nov 2010 17:53:47 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
So it seems that function doesn't handle disk exhaustion safely. (But
this is no worse than before for Geany).
Before we had safe or unsafe file saving.
On 5 November 2010 09:37, Colomban Wendling lists@herbesfolles.org wrote:
Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
On Thu, 4 Nov 2010 17:53:47 +
Nick Treleaven nick.trelea...@btinternet.com wrote:
So it seems that function doesn't handle disk exhaustion safely. (But
this is no
Le 02/11/2010 19:11, Nick Treleaven a écrit :
Hi list,
To workaround bug(s) in GVFS, I've now changed the file saving
implementation for systems with GIO in SVN trunk. See also:
http://lists.uvena.de/geany-devel/2010-November/003412.html
Please help test this. File permissions should be
34 matches
Mail list logo
