For anyone who's interested in this issue, I have opened bug 493 on it
in bugzilla:
https://bugzilla.fsl.cs.sunysb.edu/show_bug.cgi?id=493
The bug is easy to reproduce (see transcript below).
-Ken
# cd /tmp
# mkdir dir1
# mkdir dir2
# echo hello
# mkdir union
# mount -t unionfs -o dirs=/tmp/dir1=rw:/tmp/dir2=ro none union
# ls -l union
total 4
-rw-r--r-- 1 root root 6 Apr 13 11:56 file1
# ln union/file1 union/file2
# ls -l union
total 8
-rw-r--r-- 2 root root 6 Apr 13 11:56 file1
-rw-r--r-- 2 root root 6 Apr 13 11:56 file2
# rm union/file1
# ls -l union
total 4
-rw-r--r-- 0 root root 6 Apr 13 11:56 file2
#
On 4/13/06, Kenneth Duda <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
> My unionfs contained the following scary file:
>
> -rw-r--r-- 0 root root 376 Apr 12 22:39 syslog.conf.save
>
> Note that its hard link count is 0! I have never seen a file with a
> link count of 0 before. (I don't think nfsd had either. It returned
> EACCES to a client trying to open the file, although the file can be
> read locally).
>
> I unmounted my union and the underlying inode had a link count of 1 as
> expected. I remounted the union and then the unionfs inode had a link
> count of 1 too.
>
> Brrr scary. Two questions:
>
> (1) Am I right to conclude that there must be a bug if I have a
> directory entry that links to an inode with a link count of 0?
>
> (2) Anyone seen this before, have any suggestions?
>
> I will attempt to reproduce this and track down but any early pointers
> appreciated. (I am manipulating hard links via NFS, and from watching
> nfsd and unionfs get into fights before, I think I may be pushing
> things into uncharted territory. kernel-module-nfsd seems to exercise
> the fs interface in ways the system calls don't, and is more diligent
> about propagating error conditions than many.)
>
> Thanks,
> -Ken
>
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
