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: C de-Avillez
Subject: Re: 8.21.2-c53c - failure on rm/deep-2 and du/long-from-unreadable
Date: Mon, 18 Feb 2013 17:27:31 -0600

On Mon, 18 Feb 2013 22:03:51 +0000
Pádraig Brady <address@hidden> wrote:

> > 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')"

For the ecryptfs FS:

$ stat -f -c %l .
143
 python -c "import os; print os.pathconf('.','PC_PATH_MAX')"
4096

For a standard ext4:

$ stat -f -c %l .
255
$ python -c "import os; print os.pathconf('.','PC_PATH_MAX')"
4096

So ecrypts limits NAME_MAX. Indeed, running the perl snippet with $dir
set to 142 works.

Cheers,

..C..

Attachment: signature.asc
Description: PGP signature


reply via email to

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