Bug 724981

Description of problem:
A client of mine attempted to rsnapshot a mail archive directory that was encrypted with encfs.  They had about 150,000 files taking about 9gb of space.  After rsnapshot had run a couple of hours the machine ran out of memory and began swapping.

The bug is unrelated to rsnapshot because you can achieve the same results with basic commands like mv and cp.

Version-Release number of selected component (if applicable):
1.7.4

How reproducible:
Seems to be 100% reproducible.

Steps to Reproduce:
1) Setup an encfs mount with the following settings:

Version 6 configuration; created by EncFS 1.5 (revision 20080816)
Filesystem cipher: "ssl/aes", version 2:2:0 (using 2:2:1)
Filename encoding: "nameio/block", version 3:0:0 (using 3:0:1)
Key Size: 256 bits
Using PBKDF2, with 97512 iterations
Salt Size: 160 bits
Block Size: 1024 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File holes passed through to ciphertext.

2) Create a directory structure like this inside the encfs mount:
dir1
\ dir2
\ dir3
\ dir4
\ dir5

3) Fill the dirs[2-5] with anywhere from 150,000 to 200,000 files.  I used files of 100kb size.

4) cp -al dir1 dir6
5) mv dir6 dir7


Actual results:
You should see memory leak from the cp and mv operations.  My available amount of ram decreases anywhere from 400 to 800mb after operations like those complete.  The ram stays unavailable indefinitely it seems, but can be reclaimed by either rebooting or unmounting the encfs directory.

Expected results:
I'd expect to see a free amount of ram similar to what I had before I ran cp or mv.

Additional info:
I believe the hardlinks created by "cp -al" are causing the issue, because just copying or moving normal files around doesn't produce the same results.