coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 8.21.2-c53c - failure on rm/deep-2 and du/long-from-unreadable


From: Pádraig Brady
Subject: Re: 8.21.2-c53c - failure on rm/deep-2 and du/long-from-unreadable
Date: Mon, 18 Feb 2013 22:03:51 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 02/18/2013 09:25 PM, C de-Avillez wrote:
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.

So what's the limit precisely?
The total path len or the path component length.
This should output the "NAME_MAX" for the file system:
  stat -f -c %l .
I see that stat doesn't return "PATH_MAX".
In anyc ase you can see it with:
  python -c "import os; print os.pathconf('.','PC_PATH_MAX')"

I suppose we should skip here rather than fail
in any case, but it would be nice to query
these limits and auto adjust the test accordingly.

thanks,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]