On Thursday 10 October 2024 17:21:59 Steve French wrote: > On Thu, Oct 10, 2024 at 5:17 PM Steve French <smfrench@xxxxxxxxx> wrote: > > > > > > > > On Mon, Oct 7, 2024 at 1:36 PM Pali Rohár <pali@xxxxxxxxxx> wrote: > >> > >> Currently choosing how new symlinks are created is quite complicated. > >> > >> Without these patch series, by default new symlinks are created via > >> native reparse points, even when reparse=nfs or reparse=wsl is > >> specified. There is no possibility to create a NFS-style or WSL-style > >> symlink yet, and this patch series address this missing functionality. > >> When option -o sfu is specified then all new symlinks are created in > >> SFU-style, independently of -o reparse option. And when -o mfsymlinks is > >> specified then all new symlinks are created in mf style, independently > >> of -o reparse and -o sfu options. > >> > >> This patch series does not change -o sfu and -o mfsymlinks overrides, it > >> just changes the way how -o reparse is handled. > >> > > I lean toward something similar, and more intuitive - do not have > "reparse=" control symlink creation - but instead use another mount > parm (e.g. "symlink=") for that. It would be rarely used - only if > you don't want the default (windows default format too) for server > symlinks or "mfsymlinks" (for client only symlinks): > > 1) "symlink=" if specified can be set to one of five formats (with the > default being the windows format) > a) "mfsymlinks" (Mac style which is safer for many use cases since > they are "client only" symlinks which the server will never use) > Setting "symlink=mfsymlinks" will have the same effect as just > specifying "mfsymlinks" so won't break anything > b) "default" (or "windows") which uses the default symlink format > when trying to create a new symlink > c) "nfs" > d) "wsl" > e) "sfu" > 2) "reparse=" will still control how special files are created (char, > block, fifo, socket) and can be set to: > a) "nfs" (default) > b) or "wsl" > c) If "sfu" set on mount will cause special files to be created > with "sfu" format instead of using reparse points to create > 3) reading reparse points will always be supported (unless you want to > add a new parameter "reparse=none" to treat all reparse points as > empty directories) > 4) reading special files via the old "sfu" will only be supported if > you mount with "sfu" > > > > > -- > Thanks, > > Steve Ok, and how to handle creating new sockets? For me it makes sense to create new sockets in "native" AF_UNIX style - compatible with Windows WinAPI / WinSocks. Should be there also a new parameter?
