Hi On Tue, Jan 31, 2023 at 6:39 PM Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Tue, Jan 31, 2023 at 06:31:39PM +0400, Marc-André Lureau wrote: > > Hi > > > > On Mon, Jan 30, 2023 at 1:52 PM Bin Meng <bin.m...@windriver.com> wrote: > > > > > At present there is no Windows support for 9p file system. > > > This series adds initial Windows support for 9p file system. > > > > > > 'local' file system backend driver is supported on Windows, > > > including open, read, write, close, rename, remove, etc. > > > All security models are supported. The mapped (mapped-xattr) > > > security model is implemented using NTFS Alternate Data Stream > > > (ADS) so the 9p export path shall be on an NTFS partition. > > > > > > 'synth' driver is adapted for Windows too so that we can now > > > run qtests on Windows for 9p related regression testing. > > > > > > Example command line to test: > > > > > > "-fsdev local,path=c:\msys64,security_model=mapped,id=p9 -device > > > virtio-9p-pci,fsdev=p9,mount_tag=p9fs" > > > > > > Base-commit: 13356edb87506c148b163b8c7eb0695647d00c2a > > > > > > Changes in v4: > > > - Fixed 9pfs mounted as read-only issue on Windows host, adding a > > > win32_error_to_posix() to translate Windows native API error to > > > POSIX one. > > > - Fixed errors of handling symbolic links > > > - Added forward declaration to avoid using 'void *' > > > - Implemented Windows specific xxxdir() APIs for safe directory access > > > > > > > > Sorry to look a bit late at this series, I don't know what was discussed > > previously. > > > > My general feeling is that a lot of this FS portability work would be > > better handled by using GIO (even though this may add some extra > > dependency). GIO lacks some features on win32 (for example xattributes on > > win32), but they could have been proposed there too and benefiting other > > apps. > > The currently impl relies on the openat, fstatat, mkdirat, renameat, > utimensat, unlinkat functions. IIRC this was in order to deal with > various security vulnerabilities that exist due to race conditions. > AFAIK, there's no way to achieve the same with GIO as its a higher > level API which doesn't expose this kind of functionality > > Correct me if I am wrong, but that doesn't seem to hold much since the protocol doesn't keep a context (with associated fds) around. But perhaps GIO API alone can't provide safe implementations of the FileOperations callbacks? Also a lot of 9p-unix specific details may not map easily to the GIO API. How they can be ported to win32 is certainly a challenge, mostly duplicating the effort done in GIO to me.
