I’m not sure the BEAM would support UNC Paths, I’m pretty sure it only supports File Paths. You’d probably need to map the drive.

There might be some functions that accidentally do, but I doubt most would.

However, a NIF or Port could easily work around that by supplying a replacement File module (UNCFile maybe?).

The other bet would be to send a PR to the BEAM Erlang core to fix it’s underlying library (which I think they’d accept since many of the functions work anyway).

No, UNC is purely a Windows invention. The rest of the world uses URI’s. Given a UNC path like "\flsv\Finance_Dept\FUND ACCOUNTING UNIT\27112018the URI version would befile://flsv/Finance_dept/FUND%20ACCOUNTING%20UNIT/27112018`, which ‘is’ supported by unix’s via their extended interfaces (the root posix interfaces support only filepath syntax, I’m pretty sure the BEAM uses the posix calls).

You know how Windows always has to not follow standards, invent their own thing (why do you think they chose \ as the path separator instead of the already standardized /. .)

I just found this:

OTP-15333    Application(s): erts
                Related Id(s): ERL-737

                File access through UNC paths works again on Windows.
                This regression was introduced in OTP 21.

Wouldn’t work either way sadly, Windows doesn’t support accessing files over it’s shares without UNC using it’s normal interfaces (without using a network library that uses it that is).

Ooo, has it been fixed in the recently released 21.2 maybe? You should give it a try!