On Mon, 18 Feb 2013 14:55:24 -0600
C de-Avillez <address@hidden> wrote:
On Mon, 18 Feb 2013 19:38:20 +0000
Pádraig Brady <address@hidden> wrote:
On 02/18/2013 06:14 PM, C de-Avillez wrote:
Both tests failed at the same point:
foreach my $i (1..52)' -e ' { mkdir ($d, 0700) && chdir $d or die
"$!" }' File name too long at -e line 2.
I do not remember seeing this error anytime recently (but I have
been lax on running the tests, sorry).
I have attached both logs here.
Ubuntu Raring, kernel 3.8.0-6.13-generic (3.8.0-rc7), libc6
2.17-0ubuntu4.
Cheers,
..C..
Just a test setup failure, but interesting nonetheless.
Is wonder is something new adding in new PATH_MAX checks?
What file system is this? Does it happen if you use the shell
snippet in tests/du/long-from-unreadable.sh rather than the perl
snippet?
thanks,
Pádraig.
This is an ext4, no special options. Using the shell snippet succeeds:
$ dir=$(printf '%200s\n' ' ' | tr ' ' x)
$ for i in $(seq 52); do mkdir $dir|| exit -1; cd $dir||exit -1; done;
echo $?
0
xxxxxxx... (humongous directory) ...xxxxx/$
Running the perl script by itself *also* did not fail (line wrapped):
$ perl -e 'my $d = '$dir'; foreach my $i (1..52) { mkdir ($d, 0700)
&& chdir $d or die "$!" }'; echo $?
0
$
That's surprising, digging in.
..C..
Ah, got it -- the coreutils source is under my home dir; this is an
encrypted FS:
/home/hggdh/.Private on /home/hggdh type ecryptfs
(ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=<sig>,ecryptfs_fnek_sig=<sig2>)
I was running the snippets under /, which is not encrypted.
So, I guess, this is a limitation on of ecryptfs.