I've spent most of the last week+ tracking down a problem with servers that use alloctree/createfile/etc on plan9port. The problem can ultimately be tracked down to either corrupted directory entries or some other problem which causes getdirentries (called in p9p's dirread.c) to fail. The interesting thing is that it works fine except on in-memory file hierarchies created by alloctree. The really weird thing is that you can still create, open, and remove files and directories as expected as long as you specify their path, but anything which uses dirread/dirreadall dies.
Ron was able to verify that there is a low level bug which my code triggers. The only related references I could find on the net are: "cannot clone open fid" problem: http://www.mail-archive.com/9f...@9fans.net/msg05198.html http://www.mail-archive.com/9f...@9fans.net/msg05207.html Which may be related to the following kernel bug which I have verified still causes the problem on 2.6.34: https://bugzilla.kernel.org/show_bug.cgi?id=13280 Ron said he would email in a bug report as he was able to characterize it better than i can at this point. I kept on mucking with it a bit to see if I could develop a work around or nail it down further, but have not been able to do so yet. At this point I tabled working on that and am cleaning up several different attempts which contain various functional pieces. I am also cleaning up the regression tests and so far have all them working except those related to the dirread and dirreadall. With any luck I will have a minimally functional envfs (think of a distributed env with yet to be implemented typing), and possibly one of the model servers. EBo -- -- You received this message because you are subscribed to the Google Groups "Plan 9 Google Summer of Code" group. To post to this group, send email to plan9-g...@googlegroups.com. To unsubscribe from this group, send email to plan9-gsoc+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/plan9-gsoc?hl=en.
