copy big file (2GB) to encrypted filesystem through samba share

[wy]

I used debian 4.0 and made a samba public r/w share so that windows can access it. even I use latest encfs 1.4.1.1. this problem is still here. here is log by enabling encfs verbose option.

command:
encfs --public -fv /home/encrypted /home/plain.

/home/plain is shared by samba server.

It kept printing this message, after 10 minutes, it gave up.

09:09:51 (BlockFileIO.cpp:340) padding block 4260841
09:09:51 (BlockFileIO.cpp:340) padding block 4260842
09:09:51 (BlockFileIO.cpp:340) padding block 4260843
09:09:51 (BlockFileIO.cpp:340) padding block 4260844
09:09:51 (BlockFileIO.cpp:340) padding block 4260845
09:09:51 (BlockFileIO.cpp:340) padding block 4260846
09:09:51 (BlockFileIO.cpp:340) padding block 4260847
09:09:51 (BlockFileIO.cpp:340) padding block 4260848
09:09:51 (BlockFileIO.cpp:340) padding block 4260849
09:09:51 (BlockFileIO.cpp:340) padding block 4260850
09:09:51 (BlockFileIO.cpp:340) padding block 4260851
09:09:51 (BlockFileIO.cpp:340) padding block 4260852
09:09:51 (BlockFileIO.cpp:340) padding block 4260853
09:09:51 (BlockFileIO.cpp:340) padding block 4260854
09:09:51 (BlockFileIO.cpp:340) padding block 4260855
09:09:51 (BlockFileIO.cpp:340) padding block 4260856
09:09:51 (BlockFileIO.cpp:340) padding block 4260857
09:09:51 (BlockFileIO.cpp:340) padding block 4260858
09:09:51 (BlockFileIO.cpp:340) padding block 4260859
09:09:51 (BlockFileIO.cpp:340) padding block 4260860
09:09:51 (BlockFileIO.cpp:340) padding block 4260861
09:09:51 (BlockFileIO.cpp:340) padding block 4260862
09:09:51 (BlockFileIO.cpp:340) padding block 4260863
09:09:51 (BlockFileIO.cpp:340) padding block 4260864
09:09:51 (BlockFileIO.cpp:340) padding block 4260865
09:09:51 (BlockFileIO.cpp:340) padding block 4260866
09:09:51 (DirNode.cpp:805) in FileNodeDestructor for /home/encrypted/7e8SVj5,kOlkMzwj0hsHNwip (refcount 1)
09:09:51 (encfs.cpp:79) getattr on /home/encrypted/7e8SVj5,kOlkMzwj0hsHNwip
09:09:51 (DirNode.cpp:805) in FileNodeDestructor for /home/encrypted/7e8SVj5,kOlkMzwj0hsHNwip (refcount 1)
09:09:52 (DirNode.cpp:805) in FileNodeDestructor for /home/encrypted/se5i49psFQ7Gh7FzMUuImMqi (refcount 1)
09:09:52 (DirNode.cpp:815) destroying FNode /home/encrypted/se5i49psFQ7Gh7FzMUuImMqi
09:09:52 (DirNode.cpp:805) in FileNodeDestructor for /home/encrypted/ (refcount 1)
09:09:52 (DirNode.cpp:815) destroying FNode /home/encrypted/
09:09:52 (DirNode.cpp:309) Leaked FileNodes: 1
09:09:52 (DirNode.cpp:313) Leaked node: /home/encrypted/7e8SVj5,kOlkMzwj0hsHNwip

You can see error message at windows side.

Cannot copy xp400004: the specified network name is no longer available

[wy (wmyang2000)]

I found the root problem. It is in BlockFileIO::padFile. system issues truncate command. it takes long time to do this because it is a big file and connection times out.

what is the best way to solve this problem?

thanks,

[Valient Gough (vgough)]

Attached is a patch that will make encfs leave holes in files. If a block is read as all zeros, it will be assumed to be a hole and will be left as 0's when read (not deciphered).

Give that a try. If that works well for you, I'll look at putting that into encfs as an option.

[wy (wmyang2000)]

thank you. it works.

[Valient Gough (vgough)]

I've added an option to enable file holes. It will be part of the next release.

[Webu (webu)]

Thank you for doing that, I had the same problem transferring a 8GB file from Windows XP computer to Ubuntu server 8.04 running Samba + EncFS on top of ext3 shares.

I fought with the problem for many hours (without any success) until I magically found this Lauchpad, compiled the latest release and reconstructed all my encrypted folders to use the new feature. After that everything worked perfectly, like I was using an unencrypted Samba share :-) The 8GB file just flew through my network and also with medium sized files there was no wait (pauses) anymore between different files or when starting the transfer (it took a while for EncFS to "reserve" the disk space of upcoming file(s) before the actual transfer could begin).

Wehee!