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.

Reply via email to