On Jul 31 2007 12:36, Josef Sipek wrote:
>[2] http://www.filesystems.org/unionfs-odf.txt
>Instead, the new ODF code stores whiteouts as hardlinks to a special
>(regular) zero-length file in odf (/odf/whiteout), and it stores opaqueness
>information for directories in the inode GID bits in an ODF file system
>(e.g., ext2, XFS, etc.) on the local machine. This avoids the name-space
>pollution and avoids races with network file systems, while minimizing inode
>consummation in /odf.
Inode GID bits - are you reducing my 32 bits of gid_t to 31 bits?
That does not work out either.
Jan
--
On Wed, Aug 01, 2007 at 07:58:49PM +0200, Jan Engelhardt wrote:
>
> On Jul 31 2007 12:36, Josef Sipek wrote:
> >[2] http://www.filesystems.org/unionfs-odf.txt
>
> >Instead, the new ODF code stores whiteouts as hardlinks to a special
> >(regular) zero-length file in odf (/odf/whiteout), and it stores opaqueness
> >information for directories in the inode GID bits in an ODF file system
> >(e.g., ext2, XFS, etc.) on the local machine. This avoids the name-space
> >pollution and avoids races with network file systems, while minimizing inode
> >consummation in /odf.
>
> Inode GID bits - are you reducing my 32 bits of gid_t to 31 bits?
> That does not work out either.
No. The ODF code just uses the GID bits to store extra info. The GID is
_NOT_ used to store the GID of the file. The GID of the file is still coming
from the branches.
Josef 'Jeff' Sipek.
--
I abhor a system designed for the "user", if that word is a coded pejorative
meaning "stupid and unsophisticated."
- Ken Thompson