[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: root-dev-ino.c limitation
From: |
Jim Meyering |
Subject: |
Re: root-dev-ino.c limitation |
Date: |
Sun, 26 Feb 2006 22:33:30 +0100 |
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.