I have begun working on trying to resolve this bug. So far it has been
poking and breaking code to get familiar with it, and working at
understanding the problem in better detail (eg hardlinks have
implications for storing the encrypted name in the header).
As I work on this I am going to be push
** Changed in: linux (Ubuntu)
Milestone: None => natty-alpha-2
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
https://bugs.launchpad.net/bugs/344878
You received this bug notification because you are a member of Ubuntu
Bugs, whi
** Changed in: linux (Ubuntu)
Assignee: Tim Gardner (timg-tpi) => John Johansen (jjohansen)
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
https://bugs.launchpad.net/bugs/344878
You received this bug notification because you ar
@Compression: This may work for english, but will then fail for arabic, chinese
etc. filenames. The strings are just too short I'm afraid.
Disabling the base64-style encoding and removing the prefix would give us an
average limit of > 250 chars (not 255 because we'd need to encode / and NULL).
W
Quoting David Pollak (344...@bugs.launchpad.net):
> Many pieces of software (e.g., the Scala compiler) are written with EXT4
> filesystem limits in mind. Having a < 255 character limit in filenames
> is not simply a "documentation issue", but is a total blocker for using
> encrypted filesystems fo
Many pieces of software (e.g., the Scala compiler) are written with EXT4
filesystem limits in mind. Having a < 255 character limit in filenames
is not simply a "documentation issue", but is a total blocker for using
encrypted filesystems for me.
--
file name to long when creating new file (ecryp
Hello guys,
Do you encounter errors while deleting files in Windows? I'm here to
provide a solution. I've been reading several threads on this topic on
different forums where computer users were asking about this popular
error "The filename you specified is not valid or too long".
My research hel
FYI, filename length limits on Karmic, the ecryptfs limit just should be
documented somewhere -> Relase Notes?
ecryptfs: 143
encfs:174
ext4: 255
@Tyler: Squeezing out those 20 chars would bring ecryptfs on par with
encfs - might be worth it.
--
file name to long when creating new file (
Hello Tyler and every body,
I guess those who suggested compressing the filename meant for it to
take place before encrypting the filename, when there's still reasonable
redundancy in it, not after encryption and before encoding.
I like both ideas of the storage in file header and in xattr. I gue
@TheGhost luks is already available in the alternate ISO installation,
and most probably on the server installation too (IIRC, it's provided by
partman).
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
https://bugs.launchpad.net/bugs
This bug affects me as well, e.g. when I try to sync files with long
filenames via UbuntuOne. The result was, that all files, that were too
long, are lost.
Please fix this serious bug or offer encryption with luks (like fedora
does) at the ubuntu installation in the future.
--
file name to long
Affected too here on 10.04.1, you could at least put a warning in the
installer of 10.04.2 about this bug or disable the feature completely
until fixed.
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
https://bugs.launchpad.net/bugs/
I am also facing with this problem, too. I'm using Ubuntu 10.04.1 LTS
(64-bit server edition) together with encrypted home directory settings.
Is this not fixed yet? I would love to see this problem going away.
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
return
I also encountered this while building software packages.
As the text-based installer offered this, I assumed this feature is rock-solid
- how about a warning message that it isn't?
It's hard to tell from the comments - can data get lost because of this? I only
saw the warnings in the log while e
On 07/28/2010 09:44 AM, Tim Gardner wrote:
> ... how about... if the encrypted file name is too long then
> just use the unencrypted name on the lower file system ?
Dustin has suggested this before and while it would make our lives as
developers easier, I don't like it from a security standpoint.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New => In Progress
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Tim Gardner (timg-tpi)
--
file name to long when creating new file (ecryptfs_lookup: lookup_on
With regard to option 1, how about a mount option that would allow FNEK
to fail gracefully, i.e., if the encrypted file name is too long then
just use the unencrypted name on the lower file system ? This would make
the user complicit in the decision to leak unencrypted file names. This
would also a
Dustin - I was just looking into this last week. I was hoping to come up with
a way to salvage the current design of storing all metadata and ciphertext
in the lower file name for ease of implementation and performance
reasons. My intention was to improve the format. I am pretty confident
that I
Tyler,
Can you give us any update here?
Is this something that upstream will *ever* fix? This is the biggest
barrier to wider adoption of eCryptfs that I know of
:-Dustin
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
https
I am hitting this issue regularly with evolution when downloading images
in HTML mail. This has a serious impact on ordinary users who choose to
encrypt their home directory by default.
This either needs to get fixed, or encrypted filenames needs to get
turned off by default.
--
file name to lon
So nif I get errors like this:
[ 2932.820163] ecryptfs_lookup: lookup_one_len() returned [-36] on lower_dentry
=
[\\\
For anyone else hitting this, a workaround I did was to move
~/.launchpadlib to somewhere outside of $HOME, then symlink from there
to ~/.launchpadlib. Ugly, but it works until I can figure out how to
ecryptfs_enable_filename_crypto=n while use pam_ecryptfs.so.
--
file name to long when creating
I've also had a really hard time figuring out how to disable filename
encryption with the ecryptfs_enable_filename_crypto mount option using
pam (ie with encrypted HOME). Setting it in $HOME/.ecryptfsrc and
/home/.ecryptfs/$USER/.ecryptfsrc doesn't seem to work.
--
file name to long when creating
I wonder if ecryptfs_enable_filename_crypto should be turned off by
default since the option of using encrypted HOME is so prominent in the
installer. There is currently no clean way to opt out of filename
encryption without having to copy the files out of the ecryptfs mount to
a non-filename-encry
Just to chine in with a little 'me too' here. I hit this with
launchpadlib quite frequently, so many scripts that use launchpadlib
fail. This makes using filename crypto more or less unusable for (at
least some) Ubuntu developers. :(
--
file name to long when creating new file (ecryptfs_lookup: l
I see these entries in my kern.log but I'm not aware of any particularly
long filenames or any files not copying. So, is this *silently*
corrupting some collection of files somewhere in the deep recesses of my
home directory by not allowing an occasional file to be written? (I.e. I
get no warning p
When I set up eCryptfs on 10.04 and tried copying my huge home directory
(formerly ext3) to the new system, I was hit by 27,278 errors and it
cost me days of work. (Most of these paths were too long because of a
bug in other software, but many were not.)
I realize we're not voting here, but I am
The long-filename bug affects me quite often. Though the work around, to
just reduce the length of the plaintext filename, usually works ok -
albeit annoying.
However, I just experienced a case where a long ecryptfs file was copied
from one Ext4 device (from within an encrypted Ubuntu 09.10 Privat
Personally, I backup my unencrypted content to trusted, local storage
(ie, my local backup server in my house). And I backup my encrypted
content to untrusted, remote storage (such as Ubuntu One or Dropbox).
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned
Another path (as opposed to filename) length constraint surely arises
when archiving.
I was planning to back up '/home/$USER/.Private' directly to DDS tape.
But 'afio' is currently path limited to 1023 chars and 'star' to 4095
chars. Older versions and other utilities usually fare worse.
There
Another observation: Why are there so many common characters in all the
encrypted file and directory names? Here is an example where ALL names
start with the common string
CRYPTFS_FNEK_ENCRYPTED.FWYZTa2tGpIYbEZbarH8eVFOQu-N7jr7t2mD
Here is a full listing from the directory:
ECRYPTFS_FNEK_ENCRYPT
Hello,
I have a fresh install of kubuntu Lucid 10.04 LTS on x86 64 and this bug
still.
2010-05-01 11:37:30 x kernel [ 5241.275899] ecryptfs_lookup:
lookup_one_len() returned [-36] on lower_dentry =
2010-05-01 11:37:55 x kernel \\\
2010-0
Oops, sorry, that string is ~276 chars long, not ~1400, I was squinting
at the wrong number in emacs.
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
https://bugs.launchpad.net/bugs/344878
You received this bug notification because y
I discovered a new twist on this problem: It appears to me that I am not
running into the ext3 limitation of 254 chars per se, but rather
something more akin to a PATH LENGTH limitation somewhere else in the
code.
In fact, when you look at the error messages (with dmesg), you see a
pathname which
I ran into the filename length limitation, too. Would be great to see
the Huffman idea or other appropriate soluton implemented.
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
https://bugs.launchpad.net/bugs/344878
You received thi
An idea: use BCL (Basic Compression Library from http://bcl.comli.eu/)
to compress file names using some basic encoding like Huffman.
"The Basic Compression Library is released under the zlib license, which
means that it is free for anyone to use, modify and redistribute, either
in source code or
Andrei, did you compress each file name separately or their list as one
block of data?
I 've tested on a single long file name (250 characters) and gzip
compressed that to 191 bytes, bzip2 to 222 bytes.
I suppose that plain simple huffman encoding could potentially be much
more effective...
--
** Changed in: ecryptfs
Status: Confirmed => Triaged
** Changed in: ecryptfs-utils (Ubuntu)
Status: Confirmed => Triaged
--
file name to long when creating new file (ecryptfs_lookup: lookup_one_len()
returned [-36] on lower_dentry)
https://bugs.launchpad.net/bugs/344878
You receiv
38 matches
Mail list logo
