Problem with Bonobo Storage/EFS

[bulkmail dds nl]

Hi there,

I was writing some code for a little program to show the hierarchy
of a Bonobo compound document (like the 'Docview'-program that's shipped 
with MS Visual Studio).

However, every time a ran the program, it died on me with a coredump.
A minimal equivalent with the same results is:

	GnomeStorage *storage;
	GnomeStream  *stream1, *stream2;

	storage= gnome_storage_open ("efs", "myfile.efs" , GNOME_SS_RDWR|GNOME_SS_CREATE, 0644);
	
	gnome_object_unref(GNOME_OBJECT(storage));

Doing some strace'ing revealed that there's an NFS related problem (I think):

-------------------------------
open("myfile.efs", O_RDWR|O_CREAT, 0644) = 8
fcntl(8, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOLCK (No locks available)
close(8)                                = 0
write(2, "\n", 1
)                       = 1
write(2, "Bonobo", 6Bonobo)                   = 6
write(2, "-", 1-)                        = 1
write(2, "ERROR **: ", 10ERROR **: )              = 10
write(2, "Aggregate gnome_object member 0x"..., 86Aggregate gnome_object member 0x80c9c68 has been destroyed using gtk_object_* methods
) = 86
--------------------------------------

Of course, Bonobo/EFS cannot be blamed for my NFS problems, but I don't
think it should core, should it?

The above run of the program did however create a zero-byte myfile.efs. Now,
when I run my code again, again it cores, an strace reveals:

----------------------------------------------------
stat("myfile.efs", {st_mode=0, st_size=0, ...}) = 0
open("myfile.efs", O_RDWR)              = 8
read(8, "", 512)                        = 0
close(8)                                = 0
write(2, "\n", 1
)                       = 1
write(2, "Bonobo", 6Bonobo)                   = 6
write(2, "-", 1-)                        = 1
write(2, "ERROR **: ", 10ERROR **: )              = 10
write(2, "Aggregate gnome_object member 0x"..., 86Aggregate gnome_object member 0x80c9c68 has been destroyed using gtk_object_* methods
) = 86
-----------------------------------------------------------

Indeed, when checking the code in efs.c (which is a bit hard to understand due
to a lot of 'if's and 'return's), opening a file with < 512 bytes returns
a NULL. Are these the right semantics?

So I have two questions:
	- Opening a file with < 512 bytes given an error. Are these the right
	  semantics? (I'm not sure what the min. size of a valid compound
	  file would be)
	- Is there a nicer way to find out an error has occured than
	  through a core dump? Or am I just writing stupid code?

+-----------------------------------------------+
| Dirk-Jan C. Binnema <djcb@dds.nl>             |
| ICQ #50685597, http://www.casema.net/~devnull |
+-----------------------------------------------+