Other than the endian bug, the patch tested out fine. On Mon, Apr 6, 2015 at 9:20 PM, Steve French <smfrench@xxxxxxxxx> wrote: > Note build warnings (when running normal sparse checks during compile) > looks like need to resolve endian errors so that this is sure to work > in big endian, not just little endian boxes > > e.g. > > make C=1 M=fs/cifs modules CF=-D__CHECK_ENDIAN__ > > CHECK fs/cifs/cifs_unicode.c > fs/cifs/cifs_unicode.c:508:34: warning: incorrect type in assignment > (different base types) > fs/cifs/cifs_unicode.c:508:34: expected restricted __le16 > [assigned] [usertype] dst_char > fs/cifs/cifs_unicode.c:508:34: got unsigned short [unsigned] > [short] [usertype] <noident> > fs/cifs/cifs_unicode.c:517:42: warning: incorrect type in assignment > (different base types) > fs/cifs/cifs_unicode.c:517:42: expected restricted __le16 > [assigned] [usertype] dst_char > fs/cifs/cifs_unicode.c:517:42: got unsigned short [unsigned] > [short] [usertype] <noident> > fs/cifs/cifs_unicode.c:523:42: warning: incorrect type in assignment > (different base types) > fs/cifs/cifs_unicode.c:523:42: expected restricted __le16 > [assigned] [usertype] dst_char > fs/cifs/cifs_unicode.c:523:42: got unsigned short [unsigned] > [short] [usertype] <noident> > fs/cifs/cifs_unicode.c:526:42: warning: incorrect type in assignment > (different base types) > fs/cifs/cifs_unicode.c:526:42: expected restricted __le16 > [assigned] [usertype] dst_char > fs/cifs/cifs_unicode.c:526:42: got unsigned short [unsigned] > [short] [usertype] <noident> > > On Wed, Feb 4, 2015 at 1:23 AM, Nakajima Akira > <nakajima.akira@xxxxxxxxxxxx> wrote: >> Garbled characters happen by using surrogate pair for filename. >> (replace each 1 character to ??) >> >> This causes >> -- inode number duplication (when ?? and ?? exist) . >> -- can't remove file, directory. >> -- can't operate under directory. >> -- auto-remount with noserverino. >> >> >> [Steps to Reproduce] >> client# touch $(echo -e '\xf0\x9d\x9f\xa3') >> client# touch $(echo -e '\xf0\x9d\x9f\xa4') >> client# ls -li >> You see same inode number, same filename(=?? and ??) . >> >> >> >> [BUG description] >> Some functions do not consider about surrogate pair (and IVS). >> >> cifs_utf16_bytes() >> -- return incorrect length, because of not considering about surrogate pair. >> This causes problem about SymbolicLink with surrogate pair filename. >> >> cifs_mapchar() >> -- not considering about surrogate pair. >> >> cifs_from_utf16() >> -- not convert surrogate pair from SMB response (from UTF-16 to UTF-8) >> , then ls shows garbled characters. >> >> cifsConvertToUTF16() >> -- not convert surrogate pair when mapchars(SFM/SFU). > > > > -- > Thanks, > > Steve -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html