Bigger MAX_PATH (Was: Re: State of native encryption in ZFS)

[Ben RUBSON]

> On 17 may 2016 at 12:37, Niall Douglas wrote:
> 
> On 17 May 2016 at 11:58, Ben RUBSON wrote:
> 
>>>>> If FreeBSD had a bigger PATH_MAX then stackable encryptions layers
>>>>> like ecryptfs (encfs?) would be viable choices. Because encrypted
>>>>> path components are so long, one runs very rapidly into the maximum
>>>>> path on the system when PATH_MAX is so low.
>> 
>> Could you give us some examples where PATH_MAX was too low for you using ecryptfs ?
>> I (for the moment) do not run into troubles using EncFS.
> 
> Sure.
> 
> I typed this command into my encrypted store to find all paths and sort 
> them by length:
> 
>  find .  | awk '{ print length, $0 }' | sort -n -s | cut -d" " -f2-
> 
> And this was the last (longest) path returned:
> 
> (...)
> 
> (which is 1356 characters not including the mount point of the encrypted 
> drive)
> 
> This isn't a particularly crazy encrypted drive. It contains a few backups, 
> accounts, keys and so on. I'm not deliberately storing deep directory trees 
> or anything.
> 
>>> http://freebsd.1045724.n5.nabble.com/misc-184340-PATH-MAX-not-interope
>>> rable-with-Linux-td5864469.html
>> 
>> And examples where PATH_MAX is too low using Rsync ?
> 
> I've run into this when rsyncing Jenkins workspaces to FreeBSD (Jenkins 
> matrix builder generates long long paths). It isn't just rsync though, it 
> affects extracting tar archives on FreeBSD too.

Thank you Niall for your answer.
I managed to reproduce the issue creating a 900 characters path (9 subfolders of 100 characters each) and Rsyncing it to an EncFS remote folder.
No problem Rsyncing to EncFS on Linux, but it fails on FreeBSD, it only created 4 of the 9 subfolders.
So yes PATH_MAX could really be a limitation.

Why did not you make the choice to rebuild the kernel using a higher PATH_MAX (instead of using ZOL) ?

Ben