GNOME Bugzilla – Bug 596179
problem saving file (v. 1.3.7)
Last modified: 2018-04-26 10:00:52 UTC
When a file has been saved (I tried with html and php files directly on a directory root of apache http server) nearly always I have to insert a character (or modify the file again) and resave before I can see the page on the web server. I tried in two system (32 bit and 64 bit) with the ubuntu deb package of version 1.3.7 I daily use version 1.07 and there is no problem with that.
I forgot to say that the files are on a directory mounted by NFS
I've never seen this until now. Some questions to pinpoint the problem: 1) Do you see the same problem when you save files locally (not on NFS?) or only when you save on NFS? 2) can it be caused by a NFS server or client setting? (for example the async NFS option?) 3) if you start bluefish-unstable from a terminal, do you see any warnings when you save a file?
First of all I use daily bluefish 1.07 without any problem on the same two computers of the unstable version. I cannot try on local files quickly because we have a separate web server and the problem is when saving files there on NFS file server (exactly the same we use with bluefish version 1.07) The NFS have the sync option active (not the ASYNC) and I underline that is all correct. starting from a terminal the only messages I see are: rect.y+y=757, acw->h=150, sh=1200 rect.y+y=757, acw->h=150, sh=1200 rect.y+y=757, acw->h=150, sh=1200 rect.y+y=772, acw->h=150, sh=1200 rect.y+y=772, acw->h=150, sh=1200 and so on... I repeat that we are testing the unstable version on two ubuntu computer (one 32bit and one 64bit) and the situation is the same... I saw that sometimes is enough to wait 5/6 seconds and the page come alive and sometimes I have to change something on the file and resave to have the page still accessible. Thanks for your great work! Hope this could help... mARCO
the saving in 1.3.7 is done in the background in seperate threads, but that should not take 5/6 seconds, that should be finished within a second, and it should never fail. if you can compile bluefish yourself, it would be very useful if you would edit the top of src/file.c and uncomment the #define DEBUG statement, recompile, and post the output in the terminal when you save a file.
I will do it in these days... And I will let you know.
Hi, it's incredible, but compiling myself with the debug option you suggest I DO NOT HAVE the problem reported... The only thing I can imagine is that the bug is in the .deb version (in both 32bit and 64bit version) of the packages for ubuntu... I will continue using this compiled version all day to make sure it's all ok. Thanks And again... GREAT WORK!
Hi, I can't believe to my eyes... sure of what I told you I recompiled the source without the debug option... and believe me the problem comes up again... I don't know what to told you... another problem is that recompiling again with the debug on (to be able to use the software)... does not solve the problem... I'm using the same computer where the stable version always work great. (to recompile I've done a make uninstall first) ............
I forgot to report the debug lines... file_checkNsave_uri_async, using etag=1254300233:0 file_checkNsave_uri_async, saving 14699 bytes to file:///www/www.terasonline.com/index.php file_doc_fill_fileinfo, started for doc 0x1879650 and uri 0x17f7940 at fi=0x208c1c0 checkNsave_cleanup, called for 0x2322da0 the last line (checkNsave_cleanup) comes up quickly (I think it takes max a second) ... but the file is not accessible....
what is the glib version on your system? what do you see if you read the contents of the file (after saving) from the same system where bluefish is running? `cat /www/www.terasonline.com/index.php`
Here's the version: libglib2.0-0 2.20.1-0ubuntu2 The GLib library of C routines with cat I see the file correctly modified while on the web it seems that it does not exists... I CAN'T UNDERSTAND!
(In reply to comment #3) > First of all I use daily bluefish 1.07 without any problem on the same two > computers of the unstable version. JFTR: Both use different libraries for remote file handling. So you cannot compare both. > I saw that sometimes is enough to wait 5/6 seconds and the page come alive and > sometimes I have to change something on the file and resave to have the page > still accessible. It would be interesting to see the differences in the file attributes saving a file to the NFS server using the bf 1.0 and the bf 1.3 versions. Is there some tool to show file attributes? Can you try this? Regards, Daniel
> with cat I see the file correctly modified while on the web it seems that it > does not exists... I CAN'T UNDERSTAND! perhaps bluefish 1.0.7 (using gnomeVFS) flushes all changes to disk somehow, and 1.3.7 (using GVFS) does not. What happens if you enter 'sync' on the commandline, will that make the change appear on the remote server? Olivier
another interesting test: what happens if you echo "hello world" > /www/www.terasonline.com/test.txt and try to open that file on the webserver? is it always immediately available or also sometimes with a delay?
Here I'm again... Then: > It would be interesting to see the differences in the file attributes saving > a file to the NFS server using the bf 1.0 and the bf 1.3 versions. Is there > some tool to show file attributes? Can you try this? I do not know how can I do that... > perhaps bluefish 1.0.7 (using gnomeVFS) flushes all changes to disk somehow, > and 1.3.7 (using GVFS) does not. What happens if you enter 'sync' on the > commandline, will that make the change appear on the remote server? I tried several times but this does not make the changes appear... > what happens if you > echo "hello world" > /www/www.terasonline.com/test.txt > and try to open that file on the webserver? It is always immediately available! with no delay. tried several time s this one too, also with long text and cat from long files...
I found a real difference between the normal local file I/O in bluefish-1.0.7 and the file I/O done by GIO/GVFS in bluefish-1.3.7. I found the difference with the following strace command: strace -f -e 'trace=!gettimeofday,poll,futex' -o /tmp/trace src/bluefish-unstable GIO/GVFS does the following sequence: - open a file PATH/.goutputstream-XXXX - write the contents to that file - close this file - unlink PATH/FILE~ - link PATH/FILE~ to PATH/FILE - rename PATH/.goutputstream-XXXX to PATH/FILE this is a very robust sequence, if something goes wrong there is a high chance that the old data is still available. But it seems that this sequence produces the strange results on your NFS server. Not sure how to proceed now, if this is a bug in GVFS/GIO or a bug in your NFS client or your NFS server.
b.t.w I have tested on a Ubuntu 9.04 with libglib version 2.20.1-0ubuntu2 on a NFS mount to a Ubuntu 8.04 NFS server and I cannot reproduce the problem. What is your server, what is your client?
CLIENT 1: Hi, I have on ubuntu 9.04 (64bit) kernel: 2.6.28-15-generic nfs-common 1:1.1.4-1ubuntu1 CLIENT 2: ubuntu 9.10 beta kernel 2.6.31-10-generic-pae nfs-common 1:1.2.0-2ubuntu4 SERVER On the server side I have on Ubuntu 8.04.1 (64bit) kernel: 2.6.24-19-server nfs-common 1:1.1.2-2ubuntu2.1 nfs-kernel-server 1:1.1.2-2ubuntu2.1 hope this help figure out our problem... is there a simple way to change from the new way of saving to the old way? you have to know that I'm not a c/c++ programmer... thanx
there is no easy way to revert to the old code. Bluefish has switched to GIO/GVFS and this is standard GIO/GVFS behavior. can you see if the following shellscript shows the same problem on your NFS mount? #!/bin/sh date > .gstreamer-XXXX rm test.txt~ ln test.txt test.txt~ mv .gstreamer-XXXX test.txt
I tried.... even this is very strange... (be sure that every try count is more than 20 times! ) I tried with your script and on the browser I saw no problem... then I tried with: #!/bin/sh date > .gstreamer-XXXX rm test.html~ ln test.html test.html~ mv .gstreamer-XXXX test.html and the problem came up... then I tried with .php extension and no problem then I turn back with .html extension and no problem... Am I mad??? no, there is my friend near me that can confirm ^__^ I'm sorry for you that spend time with this... I can revert to stable version... but I do not know if there will be others like me...
so lets conclude: 1) this is a bug in the NFS client or server or combination 2) the bug is not always reproducable, it turns up sometimes, but also sometimes not 3) the bug is triggered by the way GIO/GVFS saves files. we can move this bug to the GIO folks, perhaps they know a workaround, but I have the feeling that the real bug is in the NFS client or server.
Thanks for your support, mARCO
moving this issue to glib. As written in #20 this really is a bug in the NFS server or client, but it is triggered by the way GIO saves it's files. It could therefore show up in any application that uses gio to save files on NFS. Is there a workaround or fix in some way possible?
I've have just upgraded my distro to ubuntu Kermit 64bit and also my nfs-server to: nfs-kernel-server 1:1.1.2-2ubuntu2.2 same problem!
Probably the same as bug #336738. *** This bug has been marked as a duplicate of bug 336738 ***