GNOME Bugzilla – Bug 110191
Gedit can't save directly to a remote file (gnome-vfs write support)
Last modified: 2006-02-06 10:04:21 UTC
If you open ftp://ftp.blah.com/foo.txt in gedit, it will open it read/only even if you have write access to this file. I'm not 100% sure it's gedit's fault. Maybe it's gnome-vfs' fault or even both's fault :) This feature works great in KDE with konqueror/kio_ftp and kwrite/kate.
*** Bug 107190 has been marked as a duplicate of this bug. ***
*** Bug 139964 has been marked as a duplicate of this bug. ***
*** Bug 141197 has been marked as a duplicate of this bug. ***
*** Bug 140998 has been marked as a duplicate of this bug. ***
From gedit-utils.c:gedit_utils_is_uri_read_only: /* FIXME: all remote files are marked as readonly */
*** Bug 143416 has been marked as a duplicate of this bug. ***
See gnome_vfs_get_file_info(), GNOME_VFS_FILE_INFO_GET_ACCESS_RIGHTS and GNOME_VFS_PERM_ACCESS_WRITABLE.
I'm working on it.
Any progress on this front? Will this be ready for Gnome 2.8 and Fedora Core 3?
*** Bug 151313 has been marked as a duplicate of this bug. ***
Whats the status on this one? If i try to edit a file over sftp the same problem still exists and were pretty close to gnome 2.8 now.
since this bug doesn't provide much info and suddenly it seems that all the world wants to edit remote files, let's sum it up: - gedit currently doesn't use (yet) gnome-vfs for writing/saving - implementing this feature is a *big* task which also implies rework some of the gedit internals - there are no (afaik) *editing* apps which use gnome-vfs for writing, so implementing may turn up problems in untested codepaths of the vfs itself This means that obviously it won't make it in gnome 2.8 (the feature freeze was weeks ago and we are even code frozen now!) Time permitting, this problem is at the top of the priority list for the next release cycle. Beside when/if it's implemented it will require *huge* testing to make sure there are no regressions... a text editor which cant save files would be pretty embarassing. As usual, patches are welcome :)
*** Bug 154688 has been marked as a duplicate of this bug. ***
Changing summary to make searching easier.
*** Bug 157223 has been marked as a duplicate of this bug. ***
Screem uses gnome-vfs for writing and has done for some time. gnome 2.8 fixes the only known problems that have been reported with it so vfs itself shouldn't show up any problems.
We took a quick look at screem, but its saving routine - despite using gnome-vfs - doesn't fullfill our needs: opening a file, write to it and close it it isn't a big deal to implement, but things gets trickier once you want to take into account the backup file, preserving permissions, symlinks etc. The bug #92896 has a more complete discussion on how we want the saving algo implemented. David: we would be more then welcome to share such code with screem (hint hint ;)
"David: we would be more then welcome to share such code with screem (hint hint ;)" Could this be put into some kind of library, and that way all programs would be able to use it. The gimp could use it for writing images, Bluefish and screem for webpages, and the many other programs that I can't think of at the moment. It would of course be a library in gnome-vfs. Nautilus does writing to gnome-vfs mounts, is that completely different than what would need to be done for gedit?
see the aforementioned bug #92896 (where David has gently added a patch): the tricky part is dealing with the creation of the backup file which is pretty specific to a text editor... I guess that every app has different enough quirks to really factor this out in a library, however feel free to prove me wrong and/or to try to at least refactor some useful functions into gnome-vfs itself.
So another feature freeze passed by and we didn't manage to get this in once again :( However this time we have not been slacking (at least not too much), in the last days we tried very hard to implement this and indeed we have a preliminary gnome-vfs saving working. I'm going to attach it here so that what we have doesn't get lost and so that other people (maybe David, of screem fame) may have a look at it since it is implemented in a fairly general way which is not tied to gedit and may be used in other projects. The file is quite a bit of code if you think it does something that should be simple enough: save a file. The reason for this is that it tries to handle with care every possible situation (as symlinks, hard links, permissions, etc) and since saving is a really important operation, the code is particularly paranoid about trying to not lose the user data. So the question seems obvious: "You had it done, why didn't you commit it?" The reasons we decided at the last second to punt this are substantially two: - we were not confortable with the current status of some methods of gnome-vfs - we were not comfortable with the changes to the code in the rest of gedit (for instance how to hadle remote read only files) So given the above concerns we really prefer to push such a big change at the very beginning of the developement cycle so that it gets all the needed testing. As soon as 2.10 will be released and works forward 2.12 is started this change will finally land in cvs. The attached file contains still some FIXMEs and needs the latest (cvs HEAD as of this moment) gnome-vfs.
Created attachment 35829 [details] gedit-vfs-utils.h
Created attachment 35830 [details] gedit-vfs-utils.c
What's the likelyhood of this fix getting into gedit for 2.12? This one issue is the only really common thread among complaints from those I convince to install Linux/GNOME. :-) Maybe a vfs-write branch, or something?
James: As pbor wrote in comment #20, this feature will land in CVS as soon as a gnome-2-10 branch will be created. Note though that due to the limitations/bugs of several gnome-vfs modules only a few protocols will be enables. We will probably define a sort of white-list of protocols that the advanced user will be able to modify.
Ahh, sorry for not reading fully.
Has the CVS branch been created? I would like to be able to test this if possible.
sorry for the late response, vfs file saving has been implemented in the new_mdi cvs branch: note that this branch is a refactoring/rewrite of large parts of gedit so it is not yet usable for day to day use (in fact it isn't even installable)... But if someone is interested, he's more than welcome to take a look and provide patches ;-) Also note that we decided to use a totally different approach for vfs saving with respect to the patch attached here.
In the mean time, you can tell people to use Bluefish or Screem. Yes, there were some problems with text editors and gnome-vfs back in 2.6 (with the truncate operation in particular), but that was fixed over a year ago, and everything's been working beautifully since then. Bluefish, in particular, can be decluttered into a nice gedit replacement until this is completed.
You can use whichever program you prefer, but unless the code changed since last time I looked at it, *I* wouldn't use bluefish to save *my* files, no thanks. Unless I have backups. Beside not all problems in gnome-vfs have been fixed... in fact some are not fixable at all due to how the different backends work, that's why we used a different approach in the new_mdi branch.
*** Bug 306111 has been marked as a duplicate of this bug. ***
I've been using it for about a day now and it seems to work fine, except for the following: - When saving remote files, it stomps on permissions. If you edit an executable script over SSH for example, every time you save it the permissions get reset to 600 - Even on local files, if a save fails (e.g. due to a permission problem), the file can't be saved any more (the save and save as menu items and buttons are greyed out) and the document can't be edited any more.
Lorenzo: thanks for testing! I think to have now fixed the permission stomping on vfs saves... The second issue that you reported still needs work, we need to handle all the errors better and set the application state accordingly.
I just did a CVS update (from anonymous CVS) and recompiled and the permissions bug is still there. Should I have waited for anonymous CVS to sync with main CVS? How do I know if the code I have is current?
I just committed so it's prolly not in anoncvs yet... you can check on cvs.gnome.org/bonsai or cvs.gnome.org/viewcvs, the relavant file is gedit-document-saver.c and of course you need to select the new_mdi cvs branch
Ok, I got the patch from bonsai. Now the permissions are fine. Ahh, fantastic!!! Thanks for coding this, and let me know if there's any further testing I can help with. :-) BTW: another thing that I miss is that the "open file" dialog box always starts up in the current directory (i.e. the gedit source directory, since the new_mdi branch can't be installed) instead of the last directory used like previous releases. I don't know if this is trivial to fix.
*** Bug 306756 has been marked as a duplicate of this bug. ***
*** Bug 313320 has been marked as a duplicate of this bug. ***
*** Bug 315922 has been marked as a duplicate of this bug. ***
I've probed new gedit from Gnome 2.12 and the problem continue. I can't write files of the network resources. It's read only. Best regards.
Jose: as written in comment 27 vfs-writing is implemented in the new_mdi developement branch of cvs. see http://live.gnome.org/Gedit_2fNewMdi to learn more about it.
And it's with HUGE pleasure that I declare this finally FIXED in cvs HEAD and in gedit 2.13.0!
Not really - this works fine with DAV and SSH for me. FTP files still open read-only. Using gedit 2.13.1
More information: Nautilus file properties tab does not show any permissions, only a message that it's unable to determine them. Despite that fact, Nautilus can upload, rename and delete files just fine. Gedit is able to open files but all files are opened read-only. Maybe this is a VFS backend bug but I know too little about VFS internal structure to find a proper place to file this bug if it's not gedit-specific so any help is appreciated.
This seems definately a gnome-vfs issue: the whole point of using vfs is that gedit doesn't know if it is dealing with ssh or with ftp etc. My wild guess is that vfs is not able to tell us the permissions and while nautilus tries anyway we take a more conservative approach and open readonly. But this is just speculation. Please open a separate bug, so that we don't annoy all the people CCed to this old bugreport.
See bug 325906 for the new entry.
FTP still opens readonly since from our tests FTP gnome-vfs method was not safe/bug-free enough to be supported in write mode. If you want to enable FTP support, make some further tests and report us your comments, please add ftp to the list of support VFS mode in /apps/gedit-2/preferences/editor/save/writable_vfs_schemes gconf key.
Been using it for a while now. So far, no problems popped up and it goes well. If I find something, I'll let you know.
I've been using this today with ftp write enabled and haven't experienced any problems. Is there anything we should be looking out for breaking in particular? What useful information can we pass back to you? Is there another bug this should be talked about in?
ftp seems to give problems with permissions (file detected as readonly etc). It may also be server specific, that is depend on the ftp server software used. I can't think of anything specific to test in particular, feel free to report any issue you notice, preferably in a new bugreport. Thanks for your feedback!
FTP works great so far. In fact it's more stable in Gedit than in Nautilus. The only problems are when the file is not writable but that's because there is no way to detect it via FTP protocol. I think it should be enabled by default in 2.14.