bug-cvs
[Top][All Lists]
Advanced

[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
> address@hidden, 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 */




reply via email to

[Prev in Thread] Current Thread [Next in Thread]