From: Giles T. <gi...@py...> - 2013-09-05 19:00:28
|
Thanks, Kevin -- I'd misinterpreted fh as being a field for a file descriptor (because the two examples I was looking at happened to be using that way) but understand it now. I'll see what I can find out with strace, both on the filesystems and on git itself. All the best, Giles On 05/09/2013 19:53, Fox, Kevin M wrote: > See: > http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FAQ > Under: > Is it possible to store a pointer to private data in the fuse_file_info structure? > > fh is for you the filesystem writer to use, not something provided by fuse. It just passes it along. > > As for git not interacting with example file systems well, I don't know. Does strace tell you anything useful? > > Thanks, > Kevin > ________________________________________ > From: Giles Thomas [gi...@py...] > Sent: Thursday, September 05, 2013 11:12 AM > To: fus...@li... > Cc: PythonAnywhere developers > Subject: [fuse-devel] fuse_file_info->fh unreliable? Or, do I need to always open a file in the read/write functions? > > Hi there, > > Sorry if this has been discussed before, but I couldn't find anything > via Google. The summary of my question: are file descriptors stored in > the fuse_file_info structure's fh member are in some way untrustworthy? > Is there any chance that something might be closing them, especially > under heavy load? > > The background: I've noticed that in the fusexmp example that comes with > the download, a file is always opened before it's read from or written > to; the xmp_open function, while it does open the file, always closes it > again and doesn't put anything in the fuse_file_info structure's fh > member. In general, fh is ignored. > > This is interesting, because I was originally looking at fusepy, and > found that when I used its simple "loopback" filesystem, then did a git > checkout into it, git gave me a "Bad file descriptor" error when trying > to write to a file. I got similar results from Joseph J. Pfeiffer's > tutorial's bbfs filesystem. Normal filesystem manipulation -- > navigating the FS from the shell, ls, touch, and so on -- worked fine, > but git checkouts obviously do a lot of filesystem work so perhaps > that's why they broke it. > > The fusexmp example handles git checkouts just fine. Both of the other > filesystems open the file in their open functions but do not close it > again, and store the FD in the structure, reusing it across operations. > > Importantly, modifying the fusepy loopback example's code to always open > the file in its read and write functions fixed the git checkout error. > (I've not been able to modify bbfs to do the same yet -- it seems to > have a lot of reference to the fuse_file_info's fh, which would take a > long time to fix so I figured it was worth asking questions before > spending the time required.) > > It looks to me as if file descriptors stored in the fuse_file_info > structure's fh member are in some way untrustworthy -- something is > closing them, perhaps. Is that right? Is it generally safer to > open/close files rather than passing file descriptors around in the > structure? > > In case it's at all relevant, all of these tests were on Ubuntu Raring > Ringtail, kernel 3.8.0-29, on Amazon EC2. > > > All the best, > > Giles > > -- > Giles Thomas<gi...@py...> > > PythonAnywhere: Develop Python in your browser > <http://pythonanywhere.com/> > > A product from PythonAnywhere LLP > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 > Registered in England and Wales as company number OC378414. > Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK > > > ------------------------------------------------------------------------------ > Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel -- Giles Thomas<gi...@py...> PythonAnywhere: Develop Python in your browser <http://pythonanywhere.com/> A product from PythonAnywhere LLP 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number OC378414. Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK |