After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 533547 - GIO doesn't permit seekable binary readwrite access to existing files.
GIO doesn't permit seekable binary readwrite access to existing files.
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
unspecified
Other Linux
: Low enhancement
: ---
Assigned To: Alexander Larsson
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-05-17 10:46 UTC by Øyvind Kolås (pippin)
Modified: 2009-11-24 13:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
workaround patch to allow seekable readwrite access to exsisting file. (1.72 KB, patch)
2008-05-17 10:48 UTC, Øyvind Kolås (pippin)
none Details | Review

Description Øyvind Kolås (pippin) 2008-05-17 10:46:05 UTC
Using GIO I have found it possible to create a new file and have seekable readwrite access to it, after having flushed and closed that file there is no way to open two new streams that I can use for new read write access. This should
be possible at least for local files.

It might be that the new call to do this is only available for some backends, like the local one. At the moment I am using a stopgap measure with a hacked GIO in GEGL to support resumable swap files, and would hope not having to port the code away from GIO again.
Comment 1 Øyvind Kolås (pippin) 2008-05-17 10:48:18 UTC
Created attachment 111039 [details] [review]
workaround patch to allow seekable readwrite access to exsisting file.

Attached the code I cobbled together when I realized what my "bugs" were due to, this isn't a solution that is feasible but I've used it and it works so the rest of the infrastructure is up to handling the task at least.
Comment 2 Hans Petter Jansson 2008-06-04 15:05:12 UTC
I suspect you already answered this question elsewhere, but why can't you open it for writing (append) and reading separately?
Comment 3 Øyvind Kolås (pippin) 2008-06-04 15:11:04 UTC
Opening the file for append would not allow seeking to an already existing position in the file, only to positions after the original end of file.
Comment 4 Øyvind Kolås (pippin) 2008-06-04 15:32:53 UTC
A potential API addition could probably be a call like:

GFileOutputStream *g_file_write (GFile *file, GCancellable *cancellable, GError **error);

That would open an output stream for an already existing file that allows overwriting data at given positions.

For my usage I need another simultanous intput stream for the same file to reflect the changes when the output stream is flushed.
Comment 5 Alexander Larsson 2008-10-20 10:33:40 UTC
The main target for the GFile API is for "document" like applications, that read the file on open, streaming conversion to an internal format and then write it on save. We don't want such apps to accidentally open a file in read-write mode (common with the gnome-vfs api), since that is not supportable on the great majority of backends. 

However, I wouldn't oppose adding an API that let you open a file in read-write mode, returning a new kind of object that has getters for the input and the output stream. As long as its clearly marked as not supported for most backends.
Comment 6 Øyvind Kolås (pippin) 2008-11-21 12:39:58 UTC
Such an API would fit the purposes where I need this. At the moment I am considering to move the affected code away from GIO again since in the end my usage for it will end up mmapping the data and thus probably should be doing all of this on a lower level of abstraction.
Comment 7 Alexander Larsson 2009-11-24 13:17:50 UTC
this is now availible w/ GIOStream, g_file_open_readwrite, etc.