As Charles wrote, we had better to wait for the persistent inode map.
I thought that persistent inodes are already implemented for many months, am I wrong?
Tomas [EMAIL PROTECTED] wrote:
While this phenomenon is rather unimportant, it is better to report here. unionfs rmdir(2) returns ENOTEMPTY when the dir is not empty correctly. But the inode number of the dir has been changed. The cause is dentry_unhash() in vfs_rmdir(). If we try recovering it by d_rehash() in unionfs_rmdir, we can success only the target dir. The unhashed children cannot be recovered.I have found another minor inode number problem. As Charles wrote, we had better to wait for the persistent inode map. You can check the different inode number with this simple code. stat returns unionfs inode number while readdir returns hidden inode number on branch. $ cd local_unionfs $ cc a.c $ ./a.out new_file shows different inode numbers. Junjiro Okajima #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <stdio.h> #include <assert.h> #include <dirent.h> #include <string.h> int main(int argc, char *argv[]) { int fd, ret; struct stat st; DIR *dp; struct dirent *de; fd = creat(argv[1], 0644); ret = fstat(fd, &st); printf("stat ino %lu\n", st.st_ino); dp = opendir("."); while ((de = readdir(dp)) != NULL) { if (strcmp(argv[1], de->d_name) == 0) break; } printf("readdir ino %lu\n", de->d_ino); return 0; } _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
_______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
