On Monday 07 May 2007, Andreas Schwab wrote: > Roland Kuhn <[email protected]> writes: > > PATH_MAX specifically counts _bytes_ not characters, so UTF-8 does not > > matter. ISTR that PATH_MAX was 256 at some point, but I just quickly > > grepped /usr/include and found various mention of 4096, so where's the > > central repository for this configuration item? A hard- > > coded value of 256 somewhere inside the kernel smells like a bug. > > There is PATH_MAX and there is NAME_MAX, and only the latter (which is > 260 for vfat) matters here. > Do you imply that Linux is unable to represent full VFAT names (255 UCS2 charaters) by design? Hmm ... testing ... looks like it, touch $(perl -e 'print "ф" x 200;') -> Name too long. So what do we do with long VFAT names? As initial post shows, they do exist.
Attachment:
pgprbCr25QFiw.pgp
Description: PGP signature
- Follow-Ups:
- Re: Long file names in VFAT broken with iocharset=utf8
- From: OGAWA Hirofumi <[email protected]>
- Re: Long file names in VFAT broken with iocharset=utf8
- References:
- Long file names in VFAT broken with iocharset=utf8
- From: Andrey Borzenkov <[email protected]>
- Re: Long file names in VFAT broken with iocharset=utf8
- From: Roland Kuhn <[email protected]>
- Re: Long file names in VFAT broken with iocharset=utf8
- From: Andreas Schwab <[email protected]>
- Long file names in VFAT broken with iocharset=utf8
- Prev by Date: Re: mkfs.ext2 triggerd RAM corruption
- Next by Date: Re: [patch] CFS scheduler, -v10
- Previous by thread: Re: Long file names in VFAT broken with iocharset=utf8
- Next by thread: Re: Long file names in VFAT broken with iocharset=utf8
- Index(es):
 |