Since I started using using 7.0, my bookmarks have been lost on four occasions, but I haven't been able to reproduce the bug at will - has anybody else noticed this? John.
On Sun, 23 Feb 2003, John Bradford wrote:
Since I started using using 7.0, my bookmarks have been lost on four occasions, but I haven't been able to reproduce the bug at will - has anybody else noticed this?
Yes, once (not a much help for bughunt) and resulted in zero-length bm.txt. Although this isn't a real fix, i thought now, that saveing into temporary file and renameing it after close may help to avoid damage when bm_srv crashes during save. Probably some error checking should be also added. --- cvs/dillo/dpi/bm_srv12.c 2003-02-16 18:45:54.000000000 +0200 +++ dillo/dpi/bm_srv12.c 2003-02-24 04:28:59.000000000 +0200 @@ -851,10 +851,12 @@ int Bms_save() BmSec *sec_node; GSList *list, *list2; GString *gstr = g_string_new(""); + gchar *BmTmp; struct stat TimeStamp; + BmTmp = g_strconcat(BmFile, ".tmp", NULL); /* open bm file */ - if (!(BmTxt = fopen(BmFile, "w"))) { + if (!(BmTxt = fopen(BmTmp, "w"))) { perror("[fopen]"); return 1; } @@ -884,6 +886,8 @@ int Bms_save() g_string_free(gstr, TRUE); fclose(BmTxt); + rename(BmTmp, BmFile); + g_free(BmTmp); /* keep track of the timestamp */ stat(BmFile, &TimeStamp);
This didn't help, bookmarks disappeared succesfully with this patch too. This time file contained lastly added bookmark in section ":s0: Unclassified" (this section didn't exist before) and i think that it happened, when i added this bookmark. On Mon, 24 Feb 2003, madis wrote:
On Sun, 23 Feb 2003, John Bradford wrote:
Since I started using using 7.0, my bookmarks have been lost on four occasions, but I haven't been able to reproduce the bug at will - has anybody else noticed this?
Yes, once (not a much help for bughunt) and resulted in zero-length bm.txt. Although this isn't a real fix, i thought now, that saveing into temporary file and renameing it after close may help to avoid damage when bm_srv crashes during save. Probably some error checking should be also added.
--- cvs/dillo/dpi/bm_srv12.c 2003-02-16 18:45:54.000000000 +0200 +++ dillo/dpi/bm_srv12.c 2003-02-24 04:28:59.000000000 +0200 @@ -851,10 +851,12 @@ int Bms_save() BmSec *sec_node; GSList *list, *list2; GString *gstr = g_string_new(""); + gchar *BmTmp; struct stat TimeStamp;
+ BmTmp = g_strconcat(BmFile, ".tmp", NULL); /* open bm file */ - if (!(BmTxt = fopen(BmFile, "w"))) { + if (!(BmTxt = fopen(BmTmp, "w"))) { perror("[fopen]"); return 1; } @@ -884,6 +886,8 @@ int Bms_save()
g_string_free(gstr, TRUE); fclose(BmTxt); + rename(BmTmp, BmFile); + g_free(BmTmp);
/* keep track of the timestamp */ stat(BmFile, &TimeStamp);
_______________________________________________ Dillo-dev mailing list Dillo-dev@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
I've been reading about these bookmarks, and I'm wondering what it is: Is it a dillo/dpi (design) problem? Or is it the bookmark server? Just curious.. ;)
Hi There!
This didn't help, bookmarks disappeared succesfully with this patch too. This time file contained lastly added bookmark in section ":s0: Unclassified" (this section didn't exist before) and i think that it happened, when i added this bookmark.
On Sun, 23 Feb 2003, John Bradford wrote:
Since I started using using 7.0, my bookmarks have been lost on four occasions, but I haven't been able to reproduce the bug at will - has anybody else noticed this?
Unfortunately this is a perverse bug: when you get accustomed to using the new bookmarks, the probability of it happening increases. I'm attaching a patch to fix it, but please let me explain the bug a bit: it happens when the bm server receives a modification request (add/modify/delete) before it has loaded the bookmarks file the first time. As most of these operations are accessed through the "modify" page (which loads the bookmarks file), they're safe, but "Bookmark this page", from the pop-up menu, is the exception. So why it was so hard to hunt? Because when you start dillo and it launches the bm server for the first time, it's vulnerable, but most probably your first action with the bookmarks will be to see them. After this first request, the bug can't happen again. If you close dillo, the bm server will remain sleeping, so if you run another dillo and issue a bare "Bookmark this page", the responding server will be the same you used the first time, so no bug can happen! The only way (AFAICS) to reproduce it, is to kill the server and issue a "Bookmark this page" operation before any other bookmark operation. How can this happen with "normal" use? Start dillo, surf the net and use bookmarks happily. At night, turn off your computer. Next day, start surfing, find a nice page and bookmark it before looking at your bookmarks. The patch: This patch does two things: 1.- Keeps a backup of the bookmarks file: bm.txt.bak 2.- Avoids not loading the bookmarks file by issuing a conditional load before any operation. Notes: * The backup file is made by renaming the original file, so if a write error happens the backup remains! * The backup is made when the original file has a size greater than 256 bytes (just in case!). Please test it as hard as you can. Livio: please add a warning message in the front and help pages of our site with a link to the patch and with the instructions to apply it. Please also state that a new release, fixing this bug will be done ASAP. Sebastian: Don't worry about the copy&paste work, it will not be included in this bug-fix release. Cheers Jorge.-
On Wed, 26 Feb 2003 10:17:14 -0300 (CLST) Jorge Arellano Cid <jcid@softhome.net> wrote:
The patch:
This patch does two things:
1.- Keeps a backup of the bookmarks file: bm.txt.bak 2.- Avoids not loading the bookmarks file by issuing a conditional load before any operation.
Notes: * The backup file is made by renaming the original file, so if a write error happens the backup remains! * The backup is made when the original file has a size greater than 256 bytes (just in case!).
Please test it as hard as you can.
The test was successful on my end. However, if I kill the server with -9, the pipe remains and the server will not reload. If I then remove the pipe, the server loads and responds "Hi browser" but no bookmarks are written. If I then try to access the bookmarks, I get a blank page. If I then close dillo, the server also stops. Of course, after reloading dillo all is well. But, no bookmarks are lost, except the ones that were chosen after the server was killed. Is there a way to overwrite the abandoned pipe (when no server is running) when restarting the server? I know sylpheed does this. Thanks for reading. Cheers, --Phil ------------------------------ Non-Determinism is not meant to be reasonable. -- M.J. 0'Donnell
On Wed, 26 Feb 2003, Phillip Warner wrote:
On Wed, 26 Feb 2003 10:17:14 -0300 (CLST) Jorge Arellano Cid <jcid@softhome.net> wrote:
The patch:
This patch does two things:
1.- Keeps a backup of the bookmarks file: bm.txt.bak 2.- Avoids not loading the bookmarks file by issuing a conditional load before any operation.
Notes: * The backup file is made by renaming the original file, so if a write error happens the backup remains! * The backup is made when the original file has a size greater than 256 bytes (just in case!).
Please test it as hard as you can.
The test was successful on my end. However, if I kill the server with -9, the pipe remains and the server will not reload. If I then remove the pipe, the server loads and responds "Hi browser" but no bookmarks are written. If I then try to access the bookmarks, I get a blank page. If I then close dillo, the server also stops.
Of course, after reloading dillo all is well.
But, no bookmarks are lost, except the ones that were chosen after the server was killed.
Is there a way to overwrite the abandoned pipe (when no server is running) when restarting the server? I know sylpheed does this.
Yes, this situation is problematic. Besides the 'kill -9', a system crash can also leave the socket's filename in /tmp... and the trouble only ends when the user realizes he must remove the socket's filename manually! After some thought, I finally found a way to check these problems using connect(). I'm not sure which error code (errno number) the different OSes will return, so I included: ECONNREFUSED, EBADF, ENOTSOCK and EADDRNOTAVAIL. GNU/Linux returns ECONNREFUSED in this case. ...and I almost forgot that sometime ago (Nov 27), Ben Wolley wrote:
Hello Jorge,
I just tried out the dpi1 bookmarks plugin, and I really like the concept. But I started wondering if someone could take advantage of a dpi URL to do something improper.
<html> <body> <a href="dpi:/bm/modify?operation=add_url2&title=home&url=http%3A%2F%2Fhome&sub mit=submit.">test</a> <img src="dpi:/bm/modify?operation=add_url2&title=home2&url=http%3A%2F%2Fhome&submit=submit." alt="test image"> </body> </html>
When I load that page, not only does the image alter my bookmarks, when I click on the link the window closes (after altering my bookmarks). This seems to be an issue similar to what is discussed in the HTTP 1.1 spec section 15.1.3.
Can POST data be sent instead? Section 9.5 says that POST should be used for "extending a database through an append operation", which is what the plugin actually does.
A hacked dpi-request using POST can also be faked, so the decision was to only allow dpi-urls from dpi-generated pages. The attached patch (against dillo-0.7.0) does five things: 1.- Keeps a backup of the bookmarks file: bm.txt.bak 2.- Avoids not loading the bookmarks file by issuing a conditional load before any operation. 3.- Takes care of EINTR while in recv(). 4.- Tests the socket's filename to be responsive and relaunchs the server if necessary. 5.- Allows dpi-requests, but only from dpi-generated pages. Most probably this will be the patch in the bug-fix release. Once again, please test it throughly! Cheers Jorge.-
Yes, I have also noticed this. First, Dillo 7.0 imported all my old bookmarks, but then everything was lost. Dillo didn't crash nor behaved strange - it just deleted my beloved (and backup'ed - thanks god!) bookmark-collection. Although my bugreport won't be very helpfull - I still hope it made some people nervous ;)! pfu -- "Contrariwise," continued Tweedledee, "if it was so, it might be, and if it were so, it would be; but as it isn't, it ain't. That's logic!" -- Lewis Carroll
On Sun, 23 Feb 2003 14:29:49 +0000 (GMT) John Bradford <john@grabjohn.com> wrote:
Since I started using using 7.0, my bookmarks have been lost on four occasions, but I haven't been able to reproduce the bug at will - has anybody else noticed this?
Yep, once. Since then I wrote a quick script that does 2 backups of the bm.txt file to save me from "disaster". Sadly I have no idea why it happened to me either :/ -- Registered Linux user #298569 QOTD: "Every morning I read the obituaries; if my name's not there, I go to work."
participants (9)
-
Daniel Pfurtscheller -
John Bradford -
Jorge Arellano Cid -
madis -
Madis Janson -
Phillip Warner -
Sebastian Geerken -
slymer＠slymer.org -
TheStar