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.meng@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.