sahlberg
commented
1 month ago That is very odd. NFSv3 has no concept of utf-8 or character encodings at all and just treats all filenames as an opaque string of bytes. (that may or may not be a valid utf8 sequence).
As such libnfs does not do any parsing or translation of the pathnames. So any filenames should be passed through libnfs unchanged.
One issue though is that afair microsofts nfs server uses code-pages just like very old smb1 servers did. This can cause incompatibilities since this makes the server re-write all the incoming and outgoing filenames on the server side. This can cause issues for any filenames that are not pure 7-bit ascii. So if your application is not "code-page" aware or is not written to translate to/from the same code-page as the windows nfs server is set to, then the application and server will have issues.
bishnu1184
Hi Ronnie,
We are using libnfs version 5.0.1.0. We are testing with two types of NFS servers. NFS servers hosted on RHEL and NFS servers hosted on Windows. For NFS servers on Windows, we are facing one issue for files with special symbols in its name ex. "unicode-filename-🎅🎄.txt". When file with above name exist on NFS share and I am calling "nfs_readdir" the name I am getting is not like shown as above. It is coming as "unicode-filename-????.txt" and because of which when using same name if I open that file, it fails to open with no_entry found error. As RHEL servers by default uses NFSv4 and as far as I know in NFSv4 it is strictly UTF-8 string encoding is used, while on Windows server it sill supports only NFSv3.1 which doesn't have UTF-8 mandatory. So is this behaviour because of this or is there any fix that can be done in libnfs to address this issue ?
Thanks, Bishnu