[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & l
From: |
Conrad T. Pino |
Subject: |
RE: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP & lstat |
Date: |
Tue, 24 May 2005 16:16:01 -0700 |
Hi Derek,
> From: Derek Price
>
> I've just checked in a patch which replaces all references to "CVS_STAT"
> with "stat" and all references to "CVS_LSTAT" with "lstat". I've made
> changes to the GNULIB modules to support this and submitted the changes
> back to GNULIB. I also checked them into CVS to speed up our resolution
> of this issue.
I'm sorry to see CVS_STAT and CVS_LSTAT go. They provided an abstraction
that made CVS less platform bound. The change makes us consistent with
GNU Lib which wouldn't be a problem if they were open to Windows native
API calls in GNU Lib code.
> >Currently the Windows build doesn't use the "lib/stat.c" module.
>
> I think it shouldn't. the GNULIB stat and lstat modules replace stat
> and lstat when some specific UNIX bugs are encountered, but rely on the
> underlying stat & lstat to work. The simplest thing to do at this point
> would probably just be to #define stat wnt_stat and #define lstat
> wnt_lstat in windows-NT/config.h.in.in.
I agree this is simpler given the removal of CVS_STAT and CVS_LSTAT and
GNULIB Windows support state.
> If you are feeling particularly motivated to ramp up the Windows support
> in GNULIB, you could try to package the work wnt_stat and wnt_lstat do
> on Windows into the GNULIB stat module and submit the whole back to
> bug-gnulib@gnu.org, but it shouldn't be necessary and there has been
> serious resistance there to adding anything to GNULIB modules like the
> GetUTCFileModTime Windows system call that check_statbuf appears to be
> making.
I'm willing to take on only what's possible and your opinion counts:
Does GNULIB include the Windows platform in it's charter?
If yes, what's your take on the resistance to Windows native API calls?
> These are good questions. Is there any similar errno macro on Windows
> to ELOOP? ELOOP happens on UNIX when a program encounters symbolic
> links like this:
>
> ln -s dir2 dir1 (dir1 --> dir2)
> ln -s dir1 dir2 (dir2 --> dir1)
>
> and then a function is asked to evaluate a path containing one of these
> elements, like `./dir1/sdir/file'. Is something similar possible with
> Windows links? If so, there should be a "correct" substitute for ELOOP
> on Windows.
The short answers are "no" and long answers follow:
The Windows "errno.h" file is below.
No Windows file system I'm aware of supports symbolic links. The closest
Windows concepts are the "Shortcut" which is a special binary file with a
"*.lnk" extension and the "reparse point". I can't say how they look to
the native file API.
The Windows NTFS supports hard links which I assume are supported in the
native API since MKS "ln" utility can creates them but their use is rare
since the Windows user interface provides no support to create them.
http://msdn.microsoft.com/library/en-us/fileio/fs/hard_links_and_junctions.asp
Microsoft doesn't support directory hard links.
I'm don't know if reparse point loops are possible.
Since our Windows support is "client" mode only do loops matter?
> Cheers,
Ditto,
> Derek
Conrad
/***
*errno.h - system wide error numbers (set by system calls)
*
* Copyright (c) 1985-1997, Microsoft Corporation. All rights reserved.
*
*Purpose:
* This file defines the system-wide error numbers (set by
* system calls). Conforms to the XENIX standard. Extended
* for compatibility with Uniforum standard.
* [System V]
*
* [Public]
*
****/
#if _MSC_VER > 1000
#pragma once
#endif
#ifndef _INC_ERRNO
#define _INC_ERRNO
#if !defined(_WIN32) && !defined(_MAC)
#error ERROR: Only Mac or Win32 targets supported!
#endif
#ifdef __cplusplus
extern "C" {
#endif
/* Define _CRTIMP */
#ifndef _CRTIMP
#ifdef _DLL
#define _CRTIMP __declspec(dllimport)
#else /* ndef _DLL */
#define _CRTIMP
#endif /* _DLL */
#endif /* _CRTIMP */
/* Define __cdecl for non-Microsoft compilers */
#if ( !defined(_MSC_VER) && !defined(__cdecl) )
#define __cdecl
#endif
/* Define _CRTAPI1 (for compatibility with the NT SDK) */
#ifndef _CRTAPI1
#if _MSC_VER >= 800 && _M_IX86 >= 300
#define _CRTAPI1 __cdecl
#else
#define _CRTAPI1
#endif
#endif
/* declare reference to errno */
#if (defined(_MT) || defined(_DLL)) && !defined(_MAC)
_CRTIMP extern int * __cdecl _errno(void);
#define errno (*_errno())
#else /* ndef _MT && ndef _DLL */
_CRTIMP extern int errno;
#endif /* _MT || _DLL */
/* Error Codes */
#define EPERM 1
#define ENOENT 2
#define ESRCH 3
#define EINTR 4
#define EIO 5
#define ENXIO 6
#define E2BIG 7
#define ENOEXEC 8
#define EBADF 9
#define ECHILD 10
#define EAGAIN 11
#define ENOMEM 12
#define EACCES 13
#define EFAULT 14
#define EBUSY 16
#define EEXIST 17
#define EXDEV 18
#define ENODEV 19
#define ENOTDIR 20
#define EISDIR 21
#define EINVAL 22
#define ENFILE 23
#define EMFILE 24
#define ENOTTY 25
#define EFBIG 27
#define ENOSPC 28
#define ESPIPE 29
#define EROFS 30
#define EMLINK 31
#define EPIPE 32
#define EDOM 33
#define ERANGE 34
#define EDEADLK 36
#define ENAMETOOLONG 38
#define ENOLCK 39
#define ENOSYS 40
#define ENOTEMPTY 41
#define EILSEQ 42
/*
* Support EDEADLOCK for compatibiity with older MS-C versions.
*/
#define EDEADLOCK EDEADLK
#ifdef __cplusplus
}
#endif
#endif /* _INC_ERRNO */