On Tue, Dec 03, 2013 at 03:48:06PM -0500, Dr Fields James Bruce wrote: > OK, it makes sense that touching a file with a bad name would get an > error, but you're seeing that cause later creates of files on the same > filesystem fail. I can't figure out why that would happen. ... So maybe there's some other problem here, but... > > >>Given that widely used ntfs-3g FUSE module also returns EILSEQ on the same case (I tested this) I would argue that a fix should be done for upstream especially since RFC5661 clearly defines that invalid UTF-8 sequence should map into NFSERR_INVAL, exact quote: "Where the client sends an invalid UTF-8 string, the server should return NFS4ERR_INVAL (see Table 5)". > > >The NFS client will then happily map that straight into EINVAL for you... This seems like a spec bug? NFS4ERR_INVAL only makes sense if you could really mandate UTF-8 on the wire all the time. But I don't know what other error would work. I guess a client could map INVAL to EILSEQ on open or lookup (is there any other reason a correct client should ever see INVAL on those ops?). Or do that only if fs_charset is supported and has FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 set. Yuch. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
