This is an automated cleanup. This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets marked as 'expired' now. Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/103 ** Changed in: qemu Status: Confirmed => Expired ** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #103 https://gitlab.com/qemu-project/qemu/-/issues/103 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1336794 Title: 9pfs does not honor open file handles on unlinked files Status in QEMU: Expired Status in Ubuntu: Confirmed Bug description: This was originally filed over here: https://bugzilla.redhat.com/show_bug.cgi?id=1114221 The open-unlink-fstat idiom used in some places to create an anonymous private temporary file does not work in a QEMU guest over a virtio-9p filesystem. Version-Release number of selected component (if applicable): qemu-kvm-1.6.2-6.fc20.x86_64 qemu-system-x86-1.6.2-6.fc20.x86_64 (those are fedora RPMs) How reproducible: Always. See this example C program: https://bugzilla.redhat.com/attachment.cgi?id=913069 Steps to Reproduce: 1. Export a filesystem with virt-manager for the guest. (type: mount, driver: default, mode: passthrough) 2. Start guest and mount that filesystem (mount -t 9p -o trans=virtio,version=9p2000.L ...) 3. Run a program that uses open-unlink-fstat (in my case it was trying to compile Perl 5.20) Actual results: fstat fails: open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/home/tst/filename") = 0 fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory) close(3) Expected results: open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3 unlink("/home/tst/filename") = 0 fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 close(3) Additional info: There was a patch put into the kernel back in '07 to handle this very problem for other filesystems; maybe its helpful: http://lwn.net/Articles/251228/ There is also a thread on LKML from last December specifically about this very problem: https://lkml.org/lkml/2013/12/31/163 There was a discussion on the QEMU list back in '11 that doesn't seem to have come to a conclusion, but did provide the test program that i've attached to this report: http://marc.info/?l=qemu-devel&m=130443605720648&w=2 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1336794/+subscriptions
