I have posted the first release candidate for DazukoFS 3.1.4. This
version will compile against the upcoming 2.6.36 Linux kernel. Since
there were various Linux-API changes, I doubt it will compile against
an older kernel.
IMPORTANT: This new version fixes an inode leak when removing
This version fixes an issue where an mmap'd file would always show the
original content, event if the file was modifed on the filesystem. It
also includes several minor fixes for handling unlikely error
With this new version, a read to the group device can return an error
if for any reason the registered process is not allowed to have an
open file descriptor to the file being accesseed. This may be because
of no more available file descriptors or because the Linux security
framework does not allow it.
This version also implements poll() for the dazukofs.ctrl device. An
application may poll to see when an event is available.
Version 3.1.4 will be the final version with me as maintainer. If you
use DazukoFS and are interested in taking over maintainership, please
let me know.
I could not find anything similar in ecryptfs code. Is this also a bug
I looked into the vfs code by i could not find out what exactly the
effect of the line above
A few words to clarify this would be great. Thx in advance and
Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.com/de/standard-terms-conditions-business-de ***************************************************
On 2010-10-19, Lino Sanfilippo <[hidden email]> wrote:
>> IMPORTANT: This new version fixes an inode leak when removing
> I assume the fix is
> dentry->d_inode->i_nlink = get_lower_inode(dentry->d_inode)->i_nlink;
> in dazukofs_rmdir(), right?
> I could not find anything similar in ecryptfs code. Is this also a
> bug in ecryptfs?
I assume that ecryptfs also has this problem. But I did not take the
time to verify this.
> I looked into the vfs code by i could not find out what exactly the
> effect of the line above is. A few words to clarify this would be
The bug (and fix) were reported on the Dazuko Savannah page:
There you will also see a simple procedure to verify the bug. This
could be done very quickly and easily to verify that ecryptfs also has
When you look at other filesystems, you see that they indeed decrement
the i_nlink count by 2 when rmdir is called. Rather than performing
this ourself, we just copy the count from the lower filesystem. Since
ecryptfs does not do this, I expect ecryptfs to also have an inode
leak with rmdir.