[Geany] Problems when "no space left on device"

FD Cami francois.cami at xxxxx
Sun Apr 27 17:54:20 UTC 2008

On Sun, 27 Apr 2008 17:35:11 +0200
Enrico Tröger <enrico.troeger at uvena.de> wrote:

> On Sun, 27 Apr 2008 12:37:28 +0200, FD Cami <francois.cami at free.fr>
> wrote:
> > > > > It may be that one way to do it is :
> > > > > * move "file" to "file~"
> > > > > * save memory buffer to "file"
> > > > > * remove "file~"
> > > > > Since this does not scale very well for big files, there should
> > > > > be some on/off option in preferences.
> > > 
> > > Well, this has no real effect in comparison to the current code.
> > 
> > It has. If step #2 "save memory buffer to file" fails, you do not
> > remove file~. You do not lose all data, which is the current
> > behaviour. I should have explained the logic better.
> I meant move and delete files has no effect for big files.

Yes, I've just realized that.

> The logic in your suggestion was pretty clear. Sorry for the confusion.

OK, no problem, thanks for clarifying.

> > > > I am going to work on that, unless a better idea comes up.
> > > 
> > > I'm not sure whether this is necessary. Wait a few days, I recently
> > > written a "backupcopy" plugin which copies the current file to a
> > > given directory after it was saved. So, this has basically the same
> > > effect as the the left "file~" in case of an error. But instead of
> > > the (IMO) ugly "~" extension, the extension can be configured, e.g.
> > > to contain a timestamp.
> > 
> > If your filesystem is full, I fail to see how this avoids losing data.
> It doesn't. But your suggestion doesn't too.
> The idea is when your filesystem is full, there is no way to save the
> current changes in your document in Geany. This should be clear.


> With the backupcopy plugin you always have a copy of the last saved
> state of your file together with a timestamp. So, even if the current
> file is emptied by the failed write operation, you still have the
> backup of the last save operation.

Yes, in a single user situation, or a multi user situation where all
users use Geany.
That's not the case in a multi-user situation when the last few edits
before the one that failed may have been done with a different editor
than Geany (yes, it happens in real life, in companies mainly).

> It is basically the same as you suggested only that the filename
> extension and the path for the backup files is configurable by default
> (through the plugin configuration).

I have to admit it is a lot prettier than what I proposed at first,
with the caveat explained above.

> > > I guess using the backupcopy plugin is probably enough to solve the
> > > problem together with a dialog box reporting the problem to the user
> > > (as Jeff suggested).
> > 
> > The dialog box is subject to the same race-condition problem I
> Not really as the dialog box tells the user *after* the failed write
> operation not before.
> I really don't want to add any code to check for disk size.

Me neither. It is ugly and not portable.

> And I also think it is sufficient to add a general dialog box telling
> the user the write operation while saving the file has failed, giving
> him the reason why it has failed (no space left, permission
> denied, ...). IMO it is not necessary to tell the user he should free
> some disk space to save the file, isn't this quite obvious?

For Geany's target user it should be obvious, yes :)

> > > And as I told before, when the system of the user is running out of
> > > disk space there are most probably bigger problems than the changes
> > > in the current file in Geany.
> > 
> > Yes, but losing the content of the file makes it even worse.
> As long as Geany is running, the content is still there.

Yeah... I like the backup copy idea (with file~ or different backup
location), as in, we still have some previous snapshot of the file.
It is not enough to have the content in RAM, but it looks like we are
not going to keep that behaviour, so OK.



More information about the Users mailing list