Re: root-dev-ino.c limitation

[Jim Meyering]

address@hidden (Eric Blake) wrote:
> I just intentionally crippled the use of getcwd in a cygwin compilation
> (gl_cv_func_getcwd_null=no gl_cv_func_getcwd_path_max=no
> when configuring), to stress-test a pending patch to cygwin readdir
> to provide d_ino.  In the process, I discovered a fundamental
> flaw in root-dev-ino.c - it expects that all pathnames derive from
> /.  But on cygwin, // is a distinct root (//.. is //, and // cannot
> be listed when doing readdir on /).  Therefore, programs
> such as pwd, when using the readdir fallback rather than
> getcwd, are unable to print directory listings when in a
> subdirectory of //.
>
> I'm wondering whether it is better to augment struct dev_ino in
> lib/dev-ino.h to have a struct root_dev_ino that holds two
> inodes on platforms known to have a distinct //, or whether
> it is better to alter algorithms that compare to root to see
> if '$dir' and '$dir/..' are the same file for arbitrary $dir.  The
> potential problem with the latter, on platforms where
> directory hard-links are permitted, is that a corrupted
> filesystem might have 'dir/..' pointing to 'dir' without
> any path back to /, in which case you DO want an error
> about pwd not being able to trace back to /.

So cygwin has are two root directories, / and //, with distinct dev/inode
pairs?  If so, then we may need a new type that corresponds to a single
pair on Unix-like systems, and to two dev/ino pairs on cygwin -- which
is needed would be selected at configure time.

It is not appropriate to change the dev_ino type, because it is used in
other contexts where the added space would be a pointless waste.