Hi, [email protected] írta: > Laszlo Attila Toth: >> We are using aufs over aufs, thus it is not an alternative now. > > CONFIG_AUFS_ROBR?
If AUFS is enabled without any suboption, the private_data is still NULL. > Waoh, I thought nobody is interested in that feature. > > >> This bug is quite strange, I know, but have you any idea what other can=20 >> set the file's private_data member? > > I am afraid the file data is broken simply, or the file may not be > aufs's, or a bug may exist in aufs1, particularly CONFIG_AUFS_ROBR code. > It is related to named pipes: The exact environment is the following. The syslog-ng is chrooted and the chroot's root directory is on AUFS, partially squashfs (as a really read-only branch). The other branch contains a named pipe, /dev/xconsole. When syslog-ng opens it, the private_data is NULL and the corresponding aufs code, au_do_open() via aufs_open_nondir() isn't called. (The pipe exists, O_CREAT flag isn't passed to the kernel). So, /dev/xconsole isn't opened by the aufs code but calling fchown() uses aufs_setattr(). I have no idea how can it be. > >> My workaround is the following: >> * additional condition: the private data must be non-null >> * if this condition is not met, the ATTR_FILE is removed from=20 >> ia->ia_valid > > But the file (which has NULL private data) may be passed to another aufs > routine, and the problem will rise again. You just stopped crashing in > setattr(). Theoretically that can be happen, but somehow that doesn't. Perhaps pipes are not used elsewhere. -- Laszlo ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
