On 04/28/2011 09:51 AM, Sassan Panahinejad wrote: > This thread seems relevant: > http://www.mail-archive.com/linux-fsdevel@vger.kernel.org/msg09159.html > Unless things have changed, it looks like the problem is in the client > kernel (although note that there isn't support in qemu, even if the > client did send an fid associated with an open file!). > Any thoughts on a workaround for this? Hrm, I don't see any workaround for this. May be we should add TFSTAT for dotl? or add a flag to TSTAT? Copying the v9fs. Thanks, JV > > > Thanks > Sassan > > On 28 April 2011 17:13, Sassan Panahinejad > wrote: > > It should be possible for guest applications to fstat a file for > which they have a valid file descriptor, even if the file has been > removed. > Demonstrated by the code sample below (fstat reports no such file > or directory). > Strangely it seems that reading from a file in this state works > fine (and when both are run, the server receives a different fid > for each). > On any other filesystem, the code runs correctly. On our 9p > filesystem it fails. > Many applications (including bash) depend on this working correctly. > I will continue investigating, but any thoughts anyone has on the > subject would be appreciated. > > > Thanks > Sassan > > > #include > #include > #include > #include > #include > > > int main(void) > { > int ret; > struct stat statbuf; > int fd = open("test.txt", O_RDWR | O_CREAT, 0666); > if (fd < 0) { > printf("open failed: %m\n"); > return 1; > } > ret = write(fd, "test1\n", 6); > if (ret < 0) { > printf("write1 failed: %m\n"); > return 1; > } > ret = unlink("test.txt"); > if (ret < 0) { > printf("unlink failed: %m\n"); > return 1; > } > ret = fstat(fd, &statbuf); > if (ret < 0) { > printf("fstat failed: %m\n"); > return 1; > } > return 0; > } > >