Re: backend question



On Thu, 2009-11-26 at 23:49 +0000, Mark Ellis wrote:
> On Thu, 2009-11-26 at 12:54 +0100, Alexander Larsson wrote:
> > 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.
> > 
> > 
> 
> Aha, that works, many thanks ! I never anticipated checking for a
> directory in open_for_read since it's preceded by those calls to
> query_info, so I assumed it shouldn't happen.

In many cases we rely on error codes rather than doing query_info calls
first because this lets us rely on the atomic properties of the
underlying systems that are availible. Checking if a file is a directory
first and then doing something on it is a race condition, as some other
process may be changing the file at the same time.

This means that exact error codes are very important.

> As to whether this call with the directory path should actually
> happen,
> I'm not sure where to start...

yeah, its a bit tricky. I guess the easiest way is to modify the gio
code a bit so that you can set a breakpoint or do some printf debugging
when this happens. But anyway, you seem to have fixed the issue.

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]