On Tue, 2009-11-24 at 22:29 +0000, Mark Ellis wrote: > Hi All > > I maintain a gvfs backend for the synce project, representing the file > system of an attached Windows Mobile device. > > It usually hangs together quite well, but I discovered a fairly large > problem recently, and would appreciate a hint. > > If I copy a directory from the remote filesystem it fails. This > appears > to be because gvfs requests a read on the directory path. Note that an > enumerate works fine. > > When I initiate the copy, I see the following sequence of calls to my > backend code. > > query_info on the directory name > enumerate on the directory > query_info on the directory name > query_fs_info on the filesystem > query_info on the directory name > query_info on the directory name > query_info on the directory name > open_for_read on the directory name > > I guess I should be including something in query_info that I've > missed, > but I can't see what, besides setting file type to directory and > content > type to inode/directory. > > Any suggestions ? That seems very weird. setting the type to directory should make that not happen. Are you doing the copy with nautilus? Might be interesting to get a backtrace from it at the point where its doing this to make sure we're not doing anything weird. However, as per the GFile docs, the proper response to opening a directory for read is to return G_IO_ERROR_IS_DIRECTORY. I would recommend you to carefully read the GFile documentations, especially the parts about error reporting. This is essentially the spec that gvfs backends has to implement, and its important to get the error conditions right.
Attachment:
signature.asc
Description: This is a digitally signed message part