2010/11/16 Dimitar Zhekov :
> On Mon, 15 Nov 2010 08:57:51 +1100
> Lex Trotman wrote:
>
>> On 11 November 2010 00:27, Nick Treleaven
>> wrote:
>> > On Wed, 10 Nov 2010 10:13:29 +1100
>> > Lex Trotman wrote:
>> >
>> >> > Also, g_file_replace_contents does have a make_backup argument we could
>>
On Mon, 15 Nov 2010 08:57:51 +1100
Lex Trotman wrote:
> On 11 November 2010 00:27, Nick Treleaven
> wrote:
> > On Wed, 10 Nov 2010 10:13:29 +1100
> > Lex Trotman wrote:
> >
> >> > Also, g_file_replace_contents does have a make_backup argument we could
> >> > provide an option for. This might h
On 11 November 2010 00:27, Nick Treleaven wrote:
> On Wed, 10 Nov 2010 10:13:29 +1100
> Lex Trotman 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 f
On 11 November 2010 00:27, Nick Treleaven wrote:
> On Wed, 10 Nov 2010 10:13:29 +1100
> Lex Trotman 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 f
On Wed, 10 Nov 2010 21:23:18 +0200
Dimitar Zhekov 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 "Input/output er
On Wed, 10 Nov 2010 18:14:04 +
Nick Treleaven wrote:
> On Wed, 10 Nov 2010 20:02:53 +0200
> Dimitar Zhekov 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 'Succe
On Wed, 10 Nov 2010 20:02:53 +0200
Dimitar Zhekov 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 unless you assign it.
On Wed, 10 Nov 2010 13:25:56 +
Nick Treleaven wrote:
> On Tue, 9 Nov 2010 21:27:07 +0200
> Dimitar Zhekov wrote:
>
> > > > Well, g_file_set_contents() uses buffered I/O, so obviously it's
> > > > acceptable too.
> > >
> > > Yes, it uses fwrite and then errno.
> >
> > Probably fwrite(), ff
On Wed, 10 Nov 2010 13:25:56 +
Nick Treleaven 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 reluctant to do so (b
On Wed, 10 Nov 2010 10:13:29 +1100
Lex Trotman 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
> g_file_replace
On Tue, 9 Nov 2010 21:27:07 +0200
Dimitar Zhekov wrote:
> > > Well, g_file_set_contents() uses buffered I/O, so obviously it's
> > > acceptable too.
> >
> > Yes, it uses fwrite and then errno.
>
> Probably fwrite(), fflush() and then errno?
> fflush() is guaranteed to set errno AFAIK.
No:
Hi again Nick,
On 10 November 2010 00:33, Nick Treleaven wrote:
> On Sat, 6 Nov 2010 11:33:41 +0200
> Dimitar Zhekov 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 for writing
> instead of g_file_replace_cont
On Tue, 9 Nov 2010 18:57:03 +
Nick Treleaven wrote:
> On Tue, 9 Nov 2010 20:28:43 +0200
> Dimitar Zhekov wrote:
>
> > With binary I/O we have fsync(), which really flushes the data.
> > Even fflush() and fclose() are not guaranteed to do that.
>
> Strange, why is that?
fsync() is in secti
On Tue, 9 Nov 2010 20:28:43 +0200
Dimitar Zhekov wrote:
> With binary I/O we have fsync(), which really flushes the data.
> Even fflush() and fclose() are not guaranteed to do that.
Strange, why is that?
> Well, g_file_set_contents() uses buffered I/O, so obviously it's
> acceptable too.
Yes,
On Tue, 9 Nov 2010 13:33:26 +
Nick Treleaven wrote:
> P.S. Thanks for sending the updated patch.
Oh, it's probably buggy. I think under Win~1, either setmode(O_BINARY)
or open(O_BINARY) should be used, since it converts the EOLN-s even for
non-buffered I/O.
--
E-gards: Jimmy
__
On Tue, 9 Nov 2010 13:33:26 +
Nick Treleaven wrote:
> On Sat, 6 Nov 2010 11:33:41 +0200
> Dimitar Zhekov 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 for writing
> instead of g_file_replace_contents
On Sat, 6 Nov 2010 11:33:41 +0200
Dimitar Zhekov 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 for writing
instead of g_file_replace_contents because if there is a better
implementation, why don't they add it?
Als
On Sun, 7 Nov 2010 13:18:48 +
Nick Treleaven wrote:
> On Thu, 4 Nov 2010 22:42:04 +0200
> Dimitar Zhekov 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.
>
> I've now made this change. I saw your patc
On Thu, 4 Nov 2010 22:42:04 +0200
Dimitar Zhekov wrote:
> On Thu, 4 Nov 2010 17:53:47 +
> Nick Treleaven 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
To summarize a long thread I'd like to propose the following process.
Its based on GIO but handling fails better.
In pseudocode (sorry if it wraps in your mailer) since I'm not sure if
we want to implement it in GIO calls, C library calls or system calls.
See below.
To write a Geany buffer conten
2010/11/6 Dimitar Zhekov :
> On Sat, 6 Nov 2010 21:31:31 +1100
> Lex Trotman wrote:
>
>> On 6 November 2010 20:33, Dimitar Zhekov 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 whic
Le 06/11/2010 06:28, Lex Trotman a écrit :
> On 6 November 2010 13:30, Colomban Wendling
> wrote:
>> Le 06/11/2010 01:58, Lex Trotman a écrit :
>>> On 6 November 2010 10:43, Colomban Wendling
>>> wrote:
Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
> On Thu, 4 Nov 2010 17:53:47 +
>
Le 06/11/2010 13:45, Dimitar Zhekov a écrit :
> On Sat, 6 Nov 2010 21:31:31 +1100
> Lex Trotman wrote:
>
>> On 6 November 2010 20:33, Dimitar Zhekov wrote:
>>
>>> If not anything else, we should use non-buffered I/O, with fsync(), and
>>> check the result of close() anyway.
>>
>> Yes.
>
> Attach
On Sat, 6 Nov 2010 21:31:31 +1100
Lex Trotman wrote:
> On 6 November 2010 20:33, Dimitar Zhekov 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 isn't safe until flushed to the
> r
On 6 November 2010 20:33, Dimitar Zhekov wrote:
> On Fri, 05 Nov 2010 23:08:57 +0100
> Colomban Wendling wrote:
>
>> Le 05/11/2010 21:33, Dimitar Zhekov a ecrit :
>> > On Fri, 05 Nov 2010 19:50:59 +0100
>> >
>> > 1. Open the file for reading and writing.
I'm not sure all non-local filesystems su
On Fri, 05 Nov 2010 23:08:57 +0100
Colomban Wendling wrote:
> Le 05/11/2010 21:33, Dimitar Zhekov a ecrit :
> > On Fri, 05 Nov 2010 19:50:59 +0100
> >
> > 1. Open the file for reading and writing.
> > 2. If the new data is longer, append the extra part only (thus claiming
> > the required disk s
On 6 November 2010 13:30, Colomban Wendling wrote:
> Le 06/11/2010 01:58, Lex Trotman a écrit :
>> On 6 November 2010 10:43, Colomban Wendling
>> wrote:
>>> Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
On Thu, 4 Nov 2010 17:53:47 +
Nick Treleaven wrote:
> So it seems tha
Le 06/11/2010 01:58, Lex Trotman a écrit :
> On 6 November 2010 10:43, Colomban Wendling
> wrote:
>> Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
>>> On Thu, 4 Nov 2010 17:53:47 +
>>> Nick Treleaven wrote:
>>>
So it seems that function doesn't handle disk exhaustion safely. (But
t
On 6 November 2010 10:43, Colomban Wendling wrote:
> Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
>> On Thu, 4 Nov 2010 17:53:47 +
>> Nick Treleaven wrote:
>>
>>> So it seems that function doesn't handle disk exhaustion safely. (But
>>> this is no worse than before for Geany).
>>
>> Before w
Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
> On Thu, 4 Nov 2010 17:53:47 +
> Nick Treleaven 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, s
On 6 November 2010 04:57, Jason Oster 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 instead of one,
Le 05/11/2010 21:33, Dimitar Zhekov a écrit :
> On Fri, 05 Nov 2010 19:50:59 +0100
> Colomban Wendling 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 av
On Fri, 05 Nov 2010 19:50:59 +0100
Colomban Wendling 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 file.
It's a well
Le 05/11/2010 20:08, Dimitar Zhekov a écrit :
> On Thu, 04 Nov 2010 23:37:28 +0100
> Colomban Wendling 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 re
On 11/05/2010 12:07 PM, Dimitar Zhekov wrote:
On Fri, 05 Nov 2010 10:57:23 -0700
Jason Oster wrote:
At the risk of making an obvious suggestion, why not use "move/rename"
instead of "copy"? (I searched the list archives and couldn't find
anything.)
Because when you move/rename filename to fi
On Thu, 04 Nov 2010 23:37:28 +0100
Colomban Wendling 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. Even if the rename
On Fri, 05 Nov 2010 10:57:23 -0700
Jason Oster 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 instea
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 fil
Le 05/11/2010 00:27, Lex Trotman a écrit :
> On 5 November 2010 09:37, Colomban Wendling
> wrote:
>> Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
>>> On Thu, 4 Nov 2010 17:53:47 +
>>> Nick Treleaven wrote:
>>>
So it seems that function doesn't handle disk exhaustion safely. (But
t
On 5 November 2010 09:37, Colomban Wendling wrote:
> Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
>> On Thu, 4 Nov 2010 17:53:47 +
>> Nick Treleaven wrote:
>>
>>> So it seems that function doesn't handle disk exhaustion safely. (But
>>> this is no worse than before for Geany).
>>
>> Before w
Le 04/11/2010 21:42, Dimitar Zhekov a écrit :
> On Thu, 4 Nov 2010 17:53:47 +
> Nick Treleaven 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, s
On Thu, 4 Nov 2010 17:53:47 +
Nick Treleaven 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 patch, it's only a few lines.
Fo
On Thu, 04 Nov 2010 18:14:17 +0100
Colomban Wendling 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 files
> > too. I'll
On Thu, 4 Nov 2010 20:37:13 +0200
Dimitar Zhekov 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 this. File perm
Le 04/11/2010 17:26, Nick Treleaven a écrit :
> On Wed, 03 Nov 2010 00:26:00 +0100
> Colomban Wendling 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. Se
On Tue, 2 Nov 2010 18:11:01 +
Nick Treleaven 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 this. File permissions shou
On Wed, 03 Nov 2010 00:26:00 +0100
Colomban Wendling 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:
> >
> > http://lists.uvena.de/geany-devel/20
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 shoul
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 preserved after
saving, and disk space exhaustion shoul
49 matches
Mail list logo
