Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft]

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Nicolas Williams (Nicolas.Williams@sun.com)
Date: 02/06/03-11:40:34 AM Z


Date: Thu, 6 Feb 2003 11:40:34 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [Dan.Oscarsson@kiconsulting.se: Comments on NFSv4 rfc3010bis-05 draft]
Message-ID: <20030206114034.A18728@binky.central.sun.com>

On Thu, Feb 06, 2003 at 06:38:27PM +0100, Dan Oscarsson wrote:
> David Robinson wrote:
> 
> >If we follow this approach, two clients that use different encoding
> >schemes may send different utf8 strings to access the same file, one
> >or both may fail depending on the form the server stored the name in.
> >Again for simplicity the server is just doing a bitwise comparision.
> >Some files may be inaccessible by certain clients, but as Nico says
> >above, we already have this today and it doesn't seem to be a problem.
> 
> Yes, we have that problem today. And it is a VERY BIG problem.
> Not for you who use ASCII, but for us who use letters outside ASCII.
> 
> NFS as it is today is unusable the moment you need more than ASCII
> and use systems with different encodings. I have had this problem
> for many years. The only working file sharing code I have had is
> the open source file sharing code I have fixed to use the same
> format on the wire. I hoped that NFSv4 finally should allow me to mount
> file systems between systems of different type, and get a working
> file sharing. If the protocol do not mandate format to use, I am sure
> I will have the same problems with NFSv4 as with previous version.

As NFSv4 stands the client can make it right, so the protocol is OK.
It'll be less painful if we at least recommend a normalization form to
use for filenames when they are created.

Let me repeat, NFSv4 is not broken here wrt normalization forms - at
worst it is sub-optimal.

Cheers,

Nico
-- 


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:12:06 AM Z CST