Re: Bug in builtin function abspath

[Alessandro Vesely]

Eli Zaretskii wrote:
> > There are two kinds of them: the other one is done with linkd, from the
> > resource kit (rktools, 11.8Mb, http://go.microsoft.com/fwlink/?LinkId=4544 )
>
> But this kind is a hard link, right?  That is, it is a directory entry
> that points to the same place on the disk data area.  Symlinks are
> different: they are special files that record the target in their
> data.

No, they are both soft links (in some sense.)

Linkd does _only_ directories. Links can point to different volumes but
not to UNC targets. The resulting object is tagged <JUNCTION> under dir.
Giving the FILE_FLAG_OPEN_REPARSE_POINT to CreateFile you can open that
object: thus it is possible to distinguish the link from the target.
However, the value of the link, the target name, is not written in the
regular data stream. There is a REPARSE_DATA stream type that can be
read using DeviceIoControl as well as BackupRead. It contains the Unicode
representation of the absolute path of the target.

> > Perhaps, Vista will amend that, and, since MS' stated purpose is to ease
> > porting, its new msvcrt will sport properly working lstat() and realpath().
>
> I'm not sure.  The current documentation in MSDN doesn't seem to have
> enough APIs to implement the full Posix functionality, AFAICS.

Hmm... there is a posix subsystem (that I've never been able to use)
thus that functionality must be somewhere. However, you are right:
the huge set of APIs they have still don't expose all of the system
capabilities.

Furthermore, the number of functionalities that make their way through the
Unix compatibility layer available via msvcrt is even lower. For example,
the stat64.c source file that comes with the Platform SDK for Windows
Server 2003 R2, implements stat64() using FindFirstFile and ends like so:

        /* now set the common fields */
        buf->st_uid = buf->st_gid = buf->st_ino = 0;
        buf->st_rdev = buf->st_dev = (_dev_t)(drive - 1); /* A=0, B=1, etc. */
        return(0);

Do you think it would be a good idea to use GetFileInformationByHandle[Ex] 
instead?
See the following for details:
http://msdn.microsoft.com/library/en-us/fileio/fs/getfileinformationbyhandle.asp
http://msdn.microsoft.com/library/en-us/fileio/fs/getfileinformationbyhandleex.asp
http://msdn.microsoft.com/library/en-us/fileio/fs/file_id_both_dir_info.asp
http://msdn.microsoft.com/library/en-us/fileio/fs/by_handle_file_information_str.asp

Those calls retrieve the number of (hard) links to a file, a volume serial 
number
that might be more reliable than the drive letter, and a unique file id that 
should
behave like an inode number. MS docs warn that "you should not use
    GetFileInformationByHandle unless your application is intended
    to be run on a limited set of operating system configurations."
In general, we could write an m4 macro that detects if we target XP (and NTFS?)
and replaces the relevant file management functions as needed.

I realize I'm slightly OT, as GNU make does not use st_ino. However, there are
lstat and readlink calls that can be replaced with the same criterion.