On Sat, Dec 7, 2024 at 6:49 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On 12/7/24 12:14 PM, Takeshi Nishimura wrote: > > On Fri, Dec 6, 2024 at 10:55 PM Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote: > >> > >> Hi! > >> > >> ---- > >> > >> Below (also attached as > >> "0001-mount.nfs4-Add-support-for-nfs-URLs_v2.patch" and available at > >> https://nrubsig.kpaste.net/e8c5cb) is version 2 of the patch which > >> adds support for nfs://-URLs in mount.nfs4, as alternative to the > >> traditional hostname:/path+-o port=<tcp-port> notation. > >> > >> * Main advantages are: > >> - Single-line notation with the familiar URL syntax, which includes > >> hostname, path *AND* TCP port number (last one is a common generator > >> of *PAIN* with ISPs) in ONE string > >> - Support for non-ASCII mount points, e.g. paths with CJKV (Chinese, > >> Japanese, ...) characters, which is typically a big problem if you try > >> to transfer such mount point information across email/chat/clipboard > >> etc., which tends to mangle such characters to death (e.g. > >> transliteration, adding of ZWSP or just '?'). > > > > - Server > > mkdir '/nfsroot11/アーカイブ' > > - Convert path at https://www.urlencoder.org/ > > '/nfsroot11/アーカイブ' ----> > > '/nfsroot11/%E3%82%A2%E3%83%BC%E3%82%AB%E3%82%A4%E3%83%96' > > - Client > > mount.nfs -o rw > > 'nfs://133.1.138.101//nfsroot11//%E3%82%A2%E3%83%BC%E3%82%AB%E3%82%A4%E3%83%96' > > /mnt > > > > Works - (◕‿◕) - 素晴らしい > > > > @Roland Mainz Thank you!! > > > >> - URL parameters are supported, providing support for future extensions > >> * Notes: > >> - Similar support for nfs://-URLs exists in other NFSv4.* > >> implementations, including Illumos, Windows ms-nfs41-client, > >> sahlberg/libnfs, ... > >> - This is NOT about WebNFS, this is only to use an URL representation > >> to make the life of admins a LOT easier > >> - Only absolute paths are supported > >> - This feature will not be provided for NFSv3 > > > > NFSv3 does not do Unicode, so this is not going to work anyway > > There are two purposes for adding an NFS URL mechanism to mount.nfs: > one is having a common way to express a server hostname and export > path; the other is to add support for percent escape. > > We still should consider NFS URLs on NFSv3 with the code points > that NFSv3 servers can support. What "code points"? NFSv3 does not use UTF-8. NFSv2/v3 use sequences of bytes and a length, and the filename encoding is up to the client and server to set. There is no protocol to figure that out, and the choices are plentiful, e.g. az_AZ.KOI8-C be_BY.CP1251 bg_BG.CP1251 bg_BG.KOI8-R fa_IR.ISIRI-3342 he_IL.CP1255 hi_IN.ISCII-DEV iu_CA.NUNACOM-8 ja_JP.eucJP ja_JP.JIS7 ja_JP.SJIS ka_GE.GEORGIAN-ACADEMY ka_GE.GEORGIAN-PS ko_KR.eucKR lo_LA.IBM-CP1133 lo_LA.MULELAO-1 mk_MK.CP1251 ru_RU.CP1251 ru_RU.KOI8-R ru_UA.CP1251 ru_UA.KOI8-U ta_IN.TSCII-0 tg_TJ.KOI8-C th_TH.TIS620 tt_RU.KOI8-C tt_RU.TATAR-CYR uk_UA.CP1251 uk_UA.KOI8-U ur_PK.CP1256 vi_VN.TCVN vi_VN.VISCII yi_US.CP1255 zh_CN.eucCN zh_CN.gb18030 zh_CN.gb2312 zh_CN.gbk zh_HK.big5 zh_HK.big5hkscs zh_TW.big5 zh_TW.eucTW ... So, which one will you choose? You do have to do that manually, by hand, at mountall time you just don't have that info. And it's even WORSE than you can imagine - many of the Asian encodings are INCOMPATIBLE (!!!) to Unicode, because the morons at the Unicode consortium did the cursed "Han unifications". This "unification" maps similar looking characters from different languages(!!) into a single Unicode code point. For CJV users it feels like forcing Americans to spell "New York" as "NEW Y卐RK", because of course uppercase and lowercase looks similar, and "O" can be substituted with the similar looking "卐". That's what the Unicode consortium did to my language. So, you just lose data if you try to do a mapping of older GBK, JIS, ... encodings to Unicode. For filenames encoded in Unicode codepoints, e.g. a URL (which uses UTF-8) there is NO WAY BACK to GBK, JIS ... imagine sort of lossy JPEG compression for filenames, you never get the original back. So forget that concept that URLs and NFSv3 will play along - that only works for English speaking users on a whiteboard, but not for Asian users in real life. For NFSv4 it works, because the protocol uses - for better or worse - UTF-8 for everything, and fortunately doesn't even attempt to do case folding. So using an URL for NFSv4/4.1/4.2 is safe. -- Internationalization&localization dev / 大阪大学 Takeshi Nishimura <takeshi.nishimura.linux@xxxxxxxxx>
