well, I don't have any ZODB conflict error, not sure it is even involved since I'm accessing a local file.
what I can see is that bobo_traverse is called two times from BaseRequest.traverse for the same request.
As Andreas said, you should be able to see the reason for that from the debugger. Typing where or w in the debugger should print the current call stack. If you wish us to take a look, you could also paste stacks for both of the calls here.
thanks for your feedback, @datakurre. I need to check it again more carefully because I don't think the stack helps. IIRC, they are the same in both calls. Once I tracked back but I got lost somewhere in the middle of waitress code. I'll come back to it asap (in days, I hope).
I[quote="zfm, post:8, topic:8985"]
So, that sounds like there is only on read per request, but there are really two requests made by the client you are using to test this? Is the method same for both requests? For example, it is pssible the the client is doing HEAD and GET requests.
I assume that you wrap the "local file" via a proxy resembling OFS.Image.File. If this assumption is correct, then you would look which of its methods accesses the file content. The most prominent of those is index_html. Your proxy could provide implementations for those that access the content of the "local file" instead. Alternatively, your proxy could emulate the data attribute of OFS.Image.File (it contains the file content) via an (intelligent) property accessing the "local file" content instead. Other attributes/methods (e.g. content_type, get_size) may need to be properly handled as well.
Sorry, I sort of understand what you say, LocalFS does a mixin with OFS.Image.File on the fly to create the proxy, but I fail to see the connection with the fact that Zope redirects from manage_workspace to manage_main. How should LocalFS know that Zope is doing a redirect and should not provide data on the first request?
Please explain your current usage LocalFS? What is it actually used for? Can't you replace it with a more modern implementation like xmldirector.connector? What functionality of LocalFS is actually needed?
There is no need to know that: manage_workspace has no need to access the file content (indeed it only looks at the available actions and which of them the current user has permissions for and makes a corresponding redirect). Thus, if you delay access to the file content until there is real need (e.g. in index_html), you do not need to know what manage_workspace does in detail (apart from the fact that is does not need to access the file content).
My recommendation: make (lasy, potentially cached) properties/methods for data (access to file content), get_size (the file size) and content_type (the file's content type). "lazy" here means that you access the file system only when those properties/methods are first accessed for the proxy object.
If you follow this recommendation, then manage_workspace will (automatically) not access the file system (as it does not use any of those attributes/methods).
Use case is simply serving a few files through Zope and I'm using it for legacy reasons and for learning experience. A simpler alternative would be to configure Apache (currently used as reverse proxy for zope). But I wanted to have this flexibility in Zope and after 15 years using it, I thought LocalFS deserved a refresh. It looks like good software to me, with the exception of many "except: pass". When I searched for an alternative to LocalFS, I did not see your add-on and anyway it needs Plone which I don't use.
Ok, thanks a lot for your detailed feedback, I understand what you mean, but it's not a solution I can follow now for several reasons, a small one of them being that I don't quite understand this redirect. What is the semantics of manage_workspace, how it differs from manage_main, and why is it redirected to manage_main. Sorry, still learning Zope, never looked into its publication system.