Richard Jones wrote: > On 11/30/05, Peter Karbaliotis <[EMAIL PROTECTED]> wrote: > >>Sebastien Delafond wrote: >> >>>On Tue, Nov 29, 2005 at 04:57:16PM -0700, Peter Karbaliotis wrote: >>> >>> >>>>Ok, I did exactly as you suggested and did not see the error. I then >>>>tried again copying the file I had started with and _did_ see the error. >>>>I copied files of various sizes and found that the problem only occurs >>>>when the file size exceeds 8192 bytes. >>> >>> >>>So let's sum it up: you only see this error when trying to: >>> >>>1) copy a file whose size > 8192 bytes >>>2) when using encfs mode in 'paranoia-mode' (other modes are OK, and >>> regular gmailfs without encfs doesn't yield any problems) >>> >>>Is this correct ? >>> >>>Richard, does this ring any bell for you ? I am not familiar with the >>>internals of EncFS, but the man page mentions that "EncFS is not a >>>true filesystem. It does not deal with any of the actual storage or >>>maintenance of files. It simply translates requests (encrypting or >>>decrypting as necessary) and passes the requests through to the >>>underlying host filesystem. Therefore any limitations of the host >>>filesystem will likely be inherited by EncFS (or possibly be further >>>limited)." >>> >>>Cheers, >>> >>>--Seb >>> >> >>It is indeed correct: only in paranoia mode and files larger that 8192 >>bytes. >> >>Please let me know if there is any further debugging that I can do and >>thanks for your efforts. >> > > > > It seems most like an EncFS issue but it could easily be tickling a > GmailFS issue. The block size for gmailfs should be much larger than > that ,although 8192 might be a fuse magic number for the size of each > write it allows through at a time (there is a big write option but I > thought the default value for large writes was larger than that). > > I don't know much about EncFS either, do either of you know what > paranoid mode does differently? > > Probably not realted but does it just encrypt the content of the files > or does it try and hide the filenames as well? Gmailfs might not deal > with some characters in filenames very well if they were encrypted. > > > Regards, > Richard. >
Filenames are always encoded in EncFS. Additionaly, standard mode uses the Blowfish cipher with a 160-bit key whereas paranoia uses AES with a 256-bit key. The only other differences are that paranoia mode turns on another two options, namely External Initialization-Vector(IV) Chaining and Block Message Authentication Code(MAC) headers. At set-up time, it is also possible to choose 'expert mode' in order to individually control each option. After some experimenation with these options, the problem seems to be with the Block MAC headers. A new gmailfs with all of the paranoia options but with Block Mac headers turned off and files larger than 8192 bytes can be written successfully. Also, a gmailfs with the standard options but wiht Block Mac headers turned on fails to write files larger than 8192 bytes. (I should also add that in each of my tests I started out with a newly created gmailfs.) >From encfs(1): Block MAC headers New to 1.1. If this is enabled, every block in every file is stored along with a cryptographic checksum (Message Authentication Code). This makes it virtually impossible to modify a file without the change being detected by EncFS. EncFS will refuse to read data which does not pass the checksum, and will log the error and return an IO error to the application. This adds substantial overhead (default being 8 bytes per filesystem block), plus computational overhead, and is not enabled by default except in paranoia mode. When this is not enabled and if EncFS is asked to read modified or corrupted data, it will have no way to verify that the decoded data is what was originally encoded. Peter -- [EMAIL PROTECTED] 780-492-7660 Academic Information and Communications Technology University of Alberta -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
