Christian Schoenebeck c81e7219e0 9pfs: fix 'Tgetattr' after unlink
With a valid file ID (FID) of an open file, it should be possible to send
a 'Tgettattr' 9p request and successfully receive a 'Rgetattr' response,
even if the file has been removed in the meantime. Currently this would
fail with ENOENT.

I.e. this fixes the following misbehaviour with a 9p Linux client:

  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)

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

This is because 9p server is always using a path name based lstat() call
which fails as soon as the file got removed. So to fix this, use fstat()
whenever we have an open file descriptor already.

Fixes: 00ede4c2529b ("virtio-9p: getattr server implementation...")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/103
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <4c41ad47f449a5cc8bfa9285743e029080d5f324.1732465720.git.qemu_oss@crudebyte.com>
2024-11-28 18:54:00 +01:00
..
2023-07-25 17:15:47 +03:00
2023-07-25 17:15:47 +03:00
2023-07-25 17:15:47 +03:00
2022-06-28 11:06:44 +02:00
2021-07-05 13:03:16 +02:00
2018-01-08 11:18:22 +01:00
2024-11-28 18:54:00 +01:00
2024-11-28 18:54:00 +01:00
2023-04-25 13:17:28 +02:00
2023-12-29 11:17:30 +11:00
2019-06-24 10:42:30 +01:00