GNOME Bugzilla – Bug 590541
No way to disable metadata saving, and no desktop-wide visibility/control
Last modified: 2009-12-30 16:16:15 UTC
Recent versions of gedit save cursor positions (and more importantly the corresponding file names) in ~/.cache/gedit/gedit-metadata.xml . In an effort to make gedit stop that, I found and unset /apps/gedit-2/preferences/editor/cursor_position/restore_cursor_position . This stopped gedit from restoring the cursor position, but did not stop gedit from saving the cursor position. Please either: - make /apps/gedit-2/preferences/editor/cursor_position/restore_cursor_position stop gedit from saving the cursor position, or - add a new preference /apps/gedit-2/preferences/editor/cursor_position/save_cursor_position which stops gedit from saving the cursor position. Personally, I'd highly prefer the former.
Cross-reference: reported to Debian as http://bugs.debian.org/539657
is the problem that setting /apps/gedit-2/preferences/editor/cursor_position/restore_cursor_position to false still restores the cursor position or that works, but you do not want the filenames saved in the metadata file? If the problem is the latter there is currently no way of turning metadata off, among other things note that: - other metadata are saved beside cursor position (e.g. the selected syntax highlighting, spell checking language, etc) - filenames are independently stored by gtk's recent files list so not saving that metadata is not going to improve "privacy" a lot - we are soon going to switch to the metadata backend introduced in gio, so if a setting needs to be introduced to avoid saving sensitive information, it should probably be at that level A possible workaround is to simply touch that file and make it readonly (well, actually you probably need to make the parent dir not writable since I guess the file gets deleted and replaced)... I think gedit should handle the "error" and go on without much noise. If it barfs, then it is a bug :)
(In reply to comment #2) > is the problem that setting > /apps/gedit-2/preferences/editor/cursor_position/restore_cursor_position to > false still restores the cursor position or that works, but you do not want the > filenames saved in the metadata file? The latter. Or, alternatively, I'd have no problem with filenames saved in the metadata file if something like the desktop-wide "clear recent documents list" would clear the metadata file. Pretty much any instance of a program saving filenames without a desktop-wide control seems like a bug. > If the problem is the latter there is currently no way of turning metadata off, > among other things note that: > - other metadata are saved beside cursor position (e.g. the selected syntax > highlighting, spell checking language, etc) I only ever saw the file saving cursor position data, and I never saw the metadata file before it started showing up with cursor position data; hence my assumption that it only saved cursor position data. But yes, that does suggest that the bug does not lie with the cursor position handling; retitling the bug accordingly. > - filenames are independently stored by gtk's recent files list so not saving > that metadata is not going to improve "privacy" a lot That one has desktop-wide visibility and control via the "Recent Documents" list. gedit's metadata doesn't. > - we are soon going to switch to the metadata backend introduced in gio, so if > a setting needs to be introduced to avoid saving sensitive information, it > should probably be at that level That seems sensible. > A possible workaround is to simply touch that file and make it readonly (well, > actually you probably need to make the parent dir not writable since I guess > the file gets deleted and replaced)... I think gedit should handle the "error" > and go on without much noise. If it barfs, then it is a bug :) That seems like a heavy-handed workaround, though it works. It does cause gedit to spew "I/O error : Permission denied" messages to stderr. (You might consider giving a filename there; IO error on *what*?) But I'd rather see a built-in mechanism, either to prevent saving this data or to give some desktop-wide control over it as with the recent documents list.
See also the gvfs bug 597017; if gedit starts using gvfs metadata, this bug can become a duplicate of that one.
Marking this as duplicate as we are now using the gvfs metadata system. *** This bug has been marked as a duplicate of bug 597017 ***