Summary: | sys-apps/coreutils-8.7: mkdir cannot create loooong directory names ? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Toralf Förster
2011-12-29 21:07:06 UTC
Well, the limit is <= 255 : tfoerste@n22 ~/tmp $ mkdir `perl -e 'print "a" x 256'` mkdir: cannot create directory `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa': File name too long your specific example is not a bug in mkdir, or any other userland software. this is the kernel rejecting your path. simply strace it: $ strace -e mkdir mkdir `perl -e 'print "a" x 256'` mkdir("...", 0777) = -1 ENAMETOOLONG (File name too long) but that is the length for a *single* component in the filename. it is not the max length for all the components summed together. notice how this works: $ rm -rf a $ mkdir -p `perl -e 'print "a/" x 256'` $ ls -R a/ $ rm -rf a i'm not entirely convinced the mlocate test failure has been properly diagnosed right, this works : $> mkdir -p `perl -e 'my $d = "d" x 15; print "$d/" x 255'` but this gives an error : mkdir -p `perl -e 'my $d = "d" x 16; print "$d/" x 255'` informing upstream ... your 2nd invocation works fine for me. as does ratcheting it up: $ mkdir -p `perl -e 'my $d = "d" x 16; print "$d/" x 2550'` $ find dddddddddddddddd/ | wc 2550 2550 55292926 (In reply to comment #4) > your 2nd invocation works fine for me. as does ratcheting it up: > $ mkdir -p `perl -e 'my $d = "d" x 16; print "$d/" x 2550'` > $ find dddddddddddddddd/ | wc > 2550 2550 55292926 Yes, but doesn't $>ls -lR dd* 2>&1 1>/dev/null | grep "File name too long" give an output for you ? (In reply to comment #5) yes, `ls` reports ENAMETOOLONG via its open(), but that's because `ls` builds up the entire path and passes it to open(). mkdir does chdir();mkdir() so its max is only ever the current component since that is really all it ever has to care about. that said, i'm not sure what your point is wrt ls ? i wouldn't necessarily call this a bug in `ls`. correct, thinko at my side. |