Hi,
yesterday an user reported that Geany behaves badly when there is no free disk space on the disk where the current file should be saved. That is, when you are editing a file in Geany, meanwhile your disk runs out of free space (extensive logging, copying large files, some process gone bad, ...) and you then save the file in Geany, it gets overwritten and the file is emptied. This is indeed bad. And there seems to be no easy way to fix it.
The only solution which comes to my mind would be to check for available disk space before trying to write the file. Unfortunately, there seems to be no portable way of doing this. There is statvfs() for Linux and some Unices but I'm not sure it is generally available. And then there is Windows which again would need some special code.
IMO, fopen() should fail to open a file for writing (mode "w") when there is no free space available and it should set errno to ENOSPC. Unfortunately, it doesn't. Instead it does open the file, returns a valid FILE* object and truncates the file. Then the following fwrite() call fails and sets errno to ENOSPC. But unfortunately at this point the file already got truncated and is empty.
I tried to first open the file with the "a" flag in append mode, then try to add some characters and if that fails, abort with an appropriate error message. And if it succeeds, re-open the file for normal writing and put the contents as usual. Unfortunately, this also doesn't work reliably. So, I'm not sure if we can/should do anything else about this.
Take this as a warning and please try to prevent the case of a full disk.
BTW, Geany is not the only app with such problems. Xfce's mousepad and SciTE have the same problem. And there are probably many more applications which similar problems.
Regards, Enrico
On Fri, 25 Apr 2008 15:12:17 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
yesterday an user reported that Geany behaves badly when there is no free disk space on the disk where the current file should be saved. That is, when you are editing a file in Geany, meanwhile your disk runs out of free space (extensive logging, copying large files, some process gone bad, ...) and you then save the file in Geany, it gets overwritten and the file is emptied. This is indeed bad. And there seems to be no easy way to fix it.
The only solution which comes to my mind would be to check for available disk space before trying to write the file. Unfortunately, there seems to be no portable way of doing this.
Hello,
Some editors (joe, gedit) move the old file to another place (in both cases, they rename the file to file~) before saving. If there is no space left, you still have the file~ to recover from, I guess. I do not like their default behaviour though, as having lots of files with ~ appended to their names is rather clunky. 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.
Cheers
F
On Sat, 26 Apr 2008 13:34:49 +0200 FD Cami francois.cami@free.fr wrote:
On Fri, 25 Apr 2008 15:12:17 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
yesterday an user reported that Geany behaves badly when there is no free disk space on the disk where the current file should be saved. That is, when you are editing a file in Geany, meanwhile your disk runs out of free space (extensive logging, copying large files, some process gone bad, ...) and you then save the file in Geany, it gets overwritten and the file is emptied. This is indeed bad. And there seems to be no easy way to fix it.
The only solution which comes to my mind would be to check for available disk space before trying to write the file. Unfortunately, there seems to be no portable way of doing this.
This does not work everytime, as far as I know there still could be a minute chance of another process writing stuff and filling up the disk before geany manages to write the file to disk.
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.
I am going to work on that, unless a better idea comes up.
Cheers
F
On Sat, Apr 26, 2008 at 6:34 AM, FD Cami francois.cami@free.fr wrote:
It may be that one way to do it is :
- move "file" to "file~"
- save memory buffer to "file"
- remove "file~"
It seems that in some cases this would actually make the situation worse, e.g.if there is just enough room for 'file', but not enough for 'file' + '~file'.
IMO it is not so critical to retain the information in the disk file, since the user was trying to overwrite it anyway. More important is to make the user fully aware that the operation failed. This is one place where I think the tiny message on the status bar is not sufficient.
Geany should display a prominent warning dialog, maybe even followed by a save-as dialog to allow the user to save the buffer to a new location, or to try again after freeing up some disk space.
- Jeff
On Sat, 26 Apr 2008 13:45:19 +0200, FD Cami francois.cami@free.fr wrote:
On Sat, 26 Apr 2008 13:34:49 +0200 FD Cami francois.cami@free.fr wrote:
On Fri, 25 Apr 2008 15:12:17 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
yesterday an user reported that Geany behaves badly when there is no free disk space on the disk where the current file should be saved. That is, when you are editing a file in Geany, meanwhile your disk runs out of free space (extensive logging, copying large files, some process gone bad, ...) and you then save the file in Geany, it gets overwritten and the file is emptied. This is indeed bad. And there seems to be no easy way to fix it.
The only solution which comes to my mind would be to check for available disk space before trying to write the file. Unfortunately, there seems to be no portable way of doing this.
This does not work everytime, as far as I know there still could be a minute chance of another process writing stuff and filling up the disk before geany manages to write the file to disk.
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. The only addition are the move from "file" to "file~" and then the deletion of "file~". Both operations doesn't work on the content of the file. Anyway, I don't like the "file~" stuff very much.
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. 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). 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.
Regards, Enrico
On Sat, 26 Apr 2008 14:32:40 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On Sat, Apr 26, 2008 at 6:34 AM, FD Cami francois.cami@free.fr wrote:
It may be that one way to do it is :
- move "file" to "file~"
- save memory buffer to "file"
- remove "file~"
It seems that in some cases this would actually make the situation worse, e.g.if there is just enough room for 'file', but not enough for 'file' + '~file'.
IMO it is not so critical to retain the information in the disk file, since the user was trying to overwrite it anyway. More important is to make the user fully aware that the operation failed. This is one place where I think the tiny message on the status bar is not sufficient.
Geany should display a prominent warning dialog, maybe even
Yes, this is a great idea. I'll add one.
followed by a save-as dialog to allow the user to save the
I don't like this too much, IMO it's better when the message in the shown dialog suggests the user to save the file at another place.
Regards, Enrico
On Sun, 27 Apr 2008 11:30:50 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sat, 26 Apr 2008 13:45:19 +0200, FD Cami francois.cami@free.fr wrote:
On Sat, 26 Apr 2008 13:34:49 +0200 FD Cami francois.cami@free.fr wrote:
On Fri, 25 Apr 2008 15:12:17 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
yesterday an user reported that Geany behaves badly when there is no free disk space on the disk where the current file should be saved. That is, when you are editing a file in Geany, meanwhile your disk runs out of free space (extensive logging, copying large files, some process gone bad, ...) and you then save the file in Geany, it gets overwritten and the file is emptied. This is indeed bad. And there seems to be no easy way to fix it.
The only solution which comes to my mind would be to check for available disk space before trying to write the file. Unfortunately, there seems to be no portable way of doing this.
This does not work everytime, as far as I know there still could be a minute chance of another process writing stuff and filling up the disk before geany manages to write the file to disk.
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.
Anyway, I don't like the "file~" stuff very much.
Me neither. That's why I proposed to remove the file~ after successfully saving the current one.
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.
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 explained above. Also, it will not work for windows users, because they mostly have a single partition, which is full or not, so you cannot save to another location (ok, perhaps a USB key or network drive) easily.
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.
Cheers
F
On Sun, 27 Apr 2008 12:37:28 +0200, FD Cami francois.cami@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. The logic in your suggestion was pretty clear. Sorry for the confusion.
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. 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 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.
explained above. Also, it will not work for windows users, because they mostly have a single partition, which is full or not, so you cannot save to another location (ok, perhaps a USB key or network drive) easily.
Nowadays this is probably also true for many Linux installations. But this is not what I want to do. I think we really shouldn't do much more than trying to write and tell the user if it failed or not. The only additional thing would be the backupcopy plugin or your "mv, write, delete" way.
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?
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.
Regards, Enrico
On Sat, Apr 26, 2008 at 9:32 PM, Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
It may be that one way to do it is :
- move "file" to "file~"
- save memory buffer to "file"
- remove "file~"
It seems that in some cases this would actually make the situation worse, e.g.if there is just enough room for 'file', but not enough for 'file' + '~file'.
If you have 'just enough room for file' Geany would warn you and you would free some space. Having just enough space for one file is usually not good anyway.
But, I don't know any sane developer that goesn't use some VCS these days. So the most you can lose are the current edits.
On Sun, 27 Apr 2008 17:35:11 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
On Sun, 27 Apr 2008 12:37:28 +0200, FD Cami francois.cami@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.
Yes.
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.
Cheers
F
On Fri, 25 Apr 2008 15:12:17 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
yesterday an user reported that Geany behaves badly when there is no free disk space on the disk where the current file should be saved. That is, when you are editing a file in Geany, meanwhile your disk runs out of free space (extensive logging, copying large files, some process gone bad, ...) and you then save the file in Geany, it gets overwritten and the file is emptied. This is indeed bad. And there seems to be no easy way to fix it.
Does g_file_set_contents() work? It says it has good error checking: http://library.gnome.org/devel/glib/stable/glib-File-Utilities.html#g-file-s...
This was introduced in GLib 2.8, but maybe we can copy the necessary functions from gfileutils.c for users with GLib 2.6. (Alternatively, we could consider raising the requirement for GLib to 2.8).
Regards, Nick
On Sun, 27 Apr 2008 19:43:58 +0200, "Milan Babuskov" milan.babuskov@gmail.com wrote:
On Sat, Apr 26, 2008 at 9:32 PM, Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
It may be that one way to do it is :
- move "file" to "file~"
- save memory buffer to "file"
- remove "file~"
It seems that in some cases this would actually make the situation worse, e.g.if there is just enough room for 'file', but not enough for 'file' + '~file'.
If you have 'just enough room for file' Geany would warn you and you would free some space. Having just enough space for one file is usually not good anyway.
But, I don't know any sane developer that goesn't use some VCS these
This is basically true for any files containing code. But sometimes you also edit just a text file or configuration file on your system which is not under some version control system.
Regards, Enrico
On Sun, 27 Apr 2008 19:54:20 +0200, FD Cami francois.cami@free.fr wrote:
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).
Not sure whether I understand you correctly. Does this mean the current edited file has been changed while editing by other editors/users? Then saving the file in Geany would overwrite the other changes. If it has been changed before starting editing it in Geany, there is no difference to the above. In any case, in such cases a version control system is IMO the only way to get around this problem.
Well, to summarise this is a bit: I'll add a dialog box now for failed write operations (for whatever reason it has failed), for backup purposes or other restoration possibilities is IMO the user responsible. He has the help of the backupcopy plugin or can use version control systems or something else.
If this is really not enough I would accept a patch to optionally do the suggested process of using a temporary for writing. But it should be optionally as this would break some things on the existing file (permissions, hard links, ...).
Regards, Enrico
On Mon, 28 Apr 2008 12:41:10 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 25 Apr 2008 15:12:17 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
yesterday an user reported that Geany behaves badly when there is no free disk space on the disk where the current file should be saved. That is, when you are editing a file in Geany, meanwhile your disk runs out of free space (extensive logging, copying large files, some process gone bad, ...) and you then save the file in Geany, it gets overwritten and the file is emptied. This is indeed bad. And there seems to be no easy way to fix it.
Does g_file_set_contents() work? It says it has good error checking: http://library.gnome.org/devel/glib/stable/glib-File-Utilities.html#g-file-s...
It would work because it does basically the same as FD Cami suggested. The contents are written to a temporary file and if this was successful it renames the temporary file to the target file. But as also mentioned in the docs for this function, hard links and set file permissions will break.
Regards, Enrico
On Tue, 29 Apr 2008 15:56:56 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
In any case, in such cases a version control system is IMO the only way to get around this problem.
I could not agree more with that.
Well, to summarise this is a bit: I'll add a dialog box now for failed write operations (for whatever reason it has failed), for backup purposes or other restoration possibilities is IMO the user responsible. He has the help of the backupcopy plugin or can use version control systems or something else.
OK.
If this is really not enough I would accept a patch to optionally do the suggested process of using a temporary for writing. But it should be optionally as this would break some things on the existing file (permissions, hard links, ...).
I will check the backupcopy plugin. At this stage it looks like it will fix most, if not all, problems. If needed I will implement the temporary file hack. Thanks for keeping the door open :)
Best regards,
Francois
On Tue, 29 Apr 2008 16:23:24 +0200, FD Cami francois.cami@free.fr wrote:
If this is really not enough I would accept a patch to optionally do the suggested process of using a temporary for writing. But it should be optionally as this would break some things on the existing file (permissions, hard links, ...).
I will check the backupcopy plugin. At this stage it looks like it
Btw the plugin code is available via SVN, to checkout use: svn co http://geany-plugins.svn.sf.net/svnroot/geany-plugins/trunk/backupcopy
(no website yet)
Regards, Enrico
On Tue, 29 Apr 2008 17:23:31 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Btw the plugin code is available via SVN, to checkout use: svn co http://geany-plugins.svn.sf.net/svnroot/geany-plugins/trunk/backupcopy
Please find the preliminary French translation attached.
Best,
Francois
On Tue, 29 Apr 2008 19:26:24 +0200 FD Cami francois.cami@free.fr wrote:
On Tue, 29 Apr 2008 17:23:31 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Btw the plugin code is available via SVN, to checkout use: svn co http://geany-plugins.svn.sf.net/svnroot/geany-plugins/trunk/backupcopy
Please find the preliminary French translation attached.
[fr.po text/x-gettext-translation (0 bytes)]
How ironic, in this thread... I will have to add a 0-sized attachment to Claws.
Working file attached, I hope.
Cheers,
F
Hello,
I couldn't resist to jump in ;) There is a little typo in the fr.po file : s/etre/être/ I added spaces before ":". (Also, in geany I do not use "greffon" for plugins as you do here, but that should be discussed on the i18n list :-) ) Updated file is attached.
FD Cami a écrit :
On Tue, 29 Apr 2008 19:26:24 +0200 FD Cami francois.cami@free.fr wrote:
On Tue, 29 Apr 2008 17:23:31 +0200 Enrico Tröger enrico.troeger@uvena.de wrote:
Btw the plugin code is available via SVN, to checkout use: svn co http://geany-plugins.svn.sf.net/svnroot/geany-plugins/trunk/backupcopy
Please find the preliminary French translation attached.
[fr.po text/x-gettext-translation (0 bytes)]
How ironic, in this thread... I will have to add a 0-sized attachment to Claws.
Working file attached, I hope.
Cheers,
F
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
Hi Jean-Philippe,
On Wed, 30 Apr 2008 22:34:57 +0200 Jean-Philippe skateinmars@skateinmars.net wrote:
Hello,
I couldn't resist to jump in ;)
The more the merrier :)
There is a little typo in the fr.po file : s/etre/être/ I added spaces before ":".
Thanks !
(Also, in geany I do not use "greffon" for plugins as you do here, but that should be discussed on the i18n list :-) )
I've just subscribed to that list. :)
Updated file is attached.
Thanks for proofreading.
Cheers
F
On Wed, 30 Apr 2008 22:34:57 +0200, Jean-Philippe skateinmars@skateinmars.net wrote:
Hello,
I couldn't resist to jump in ;) There is a little typo in the fr.po file : s/etre/être/ I added spaces before ":". (Also, in geany I do not use "greffon" for plugins as you do here, but that should be discussed on the i18n list :-) ) Updated file is attached.
Thank you both, I finally committed the file.
Regards, Enrico