Yes, that fix is in the current code.
But what I am talking about is actually the opposite: initializing or
mounting an encfs volume in such a way that it *exports* a
case-insensitive filesystem. That is:
$ echo "hi" > /encfs/AbC
# filename preserves case:
$ ls /encfs/
AbC
# any attempt to open/stat a file works regardless of case:
$ cat /encfs/abc
hi
$ cat /encfs/ABC
hi
$ cat /encfs/aBc
hi
This is how HFS+ behaves by default (and I think also NTFS): they
preserve and report the exact case specified, but they *match* (on
open/read/...) as though case were stripped away, if there a file
exists which would match in a case-insensitive fashion.
I've spelunked through the code a bit and I think there are two
potential sources of complexity:
1. Filenames are used and matched in several different places. In
addition to the backing store (the encrypted folder), they are also
kept in an open file map in the `context` object (keyed off filename).
Obvious choices here are:
- Key the open file map off of lowercase strings. It seems the key is
not used directly, and where it was, the file object itself maintains
its correct (non-lowercased) name.
- Leave the map as is, and allow the open file map to contain
duplicate entries in case of differently-cased requests mapping to the
same file. It's unclear if this is safe, given how the map is used.
2. Matching in the backing store would have to account for potential
case mismatches at every level of the path, since the filesystem case
behavior obviously wouldn't work once different case logical names are
mapped to unrelated encrypted strings. The two obvious ways to deal
with this seem to be:
- In case /Requested/file/PaTh doesn't directly map through the cipher
to files in the backing store:
- stat each segment
- starting at first failed segment, list parent directory, decrypt
all contained filenames, and match against decrypted names in
case-insensitive fashion
- recurse to next path segment
This might not be insane if a request for /Requested/file/PaTh already
has to open each directory in the path in the current system. (My
FUSE/UNIX VFS memory is fuzzy on this.) Otherwise, this seems nasty.
- Always keep files in the backing store named based on
cipher(lowercase(name)) rather than just cipher(name). Additionally
track actual filenames (with case) in some metadata (in a header block
of the actual file, in xattrs, or in .encfs.xml sidecars
per-directory).
This seems more "right" at some level, but also more dangerous in
practice in its reliance on sadly still ill-supported or unreliable
features like xattrs. (I could easily imagine this working fine
locally and on, say, Dropbox, but blowing up on GDrive, rsync, etc.
due to dropped xattrs.)
Thoughts?
Am I missing a simpler choice?
On Fri, Aug 17, 2012 at 5:00 PM, Andrzej Zawadzki <a.zawad...@gmail.com> wrote:
> I remember that when I browsed through the sources of EncFS, the fix
> was already there. I think this is the issue that you're dealing with:
> http://code.google.com/p/encfs/issues/detail?id=103&can=1&q=%23103
>
> Andrzej
>
> 2012/8/17 Jonathan Ragan-Kelley <katok...@gmail.com>:
>> For better or worse, both major desktop OSes are stuck with a legacy
>> of case-insensitive filesystems. As a result, while the OSes
>> themselves work fine with case-sensitive filesystems these days, many
>> applications seriously misbehave when run or when working off of a
>> case-sensitive filesystem.
>>
>> I have recently run into this in a situation where encfs would be
>> ideal, but discovered with some pain that, by default at least, it
>> exposes a case-sensitive volume when run under fuse4x on Mac OS X.
>>
>> Is there a current workaround or option to enable HFS+-like
>> case-insensitive behavior?
>>
>> How straightforward would it be to add one? (I'm glad to try it
>> myself, but would appreciate a word of warning before I try if the
>> experienced developers expect it to be a losing proposition, either
>> technically or because you wouldn't accept such a patch.)
>>
>> Thanks.
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Encfs-users mailing list
>> Encfs-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/encfs-users
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Encfs-users mailing list
Encfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/encfs-users
