[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS update: /ccvs/lib/

From: Derek Price
Subject: Re: CVS update: /ccvs/lib/
Date: Mon, 13 Jun 2005 09:59:17 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

conradpino@cvshome.org wrote:

> * libcvs.dsp: Add files "filenamecat.h" and "lstat.c" to project.

Your change to filenamecat.h is correct - that's a rename of the
path-concat module from GNULIB, but I don't think you want lib/lstat.h &
lib/lstat.c on Windows.  lib/lstat.c contains a wrapper for lstat that
works around a very specifc lstat bug on some UNIX systems & lib/lstat.h
is going to override the definition of lstat from windows/config.h. 
Perhaps leaving out lib/lstat.c & lib/lstat.h and adding a
windows-NT/lstat.h like the following would be a more complete solution?

#ifndef LSTAT_H
# define LSTAT_H
# include <unistd.h>
# define lstat stat

I think window-NT/filesubr.h will need to include "lstat.h" after this
change as well.

By the way, while I am thinking about it, re our earlier discussions of
Cygwin and Windows replacement functions, Cygwin settled on using .lnk
files (Windows shortcuts) as the Windows representation of UNIX
symlinks.  It might make sense for CVS on Windows to use stat & lstat
wrappers that behaved similarly.  i.e. stat would follow .lnk references
until they resolved to something real or failed to (check POSIX but I
think this would mean an error) and an lstat that returned the actual
stat information from the .lnk file.  Of course, this would probably
also require wrappers for "open" and "fopen" that also followed
shortcuts as if they were symlinks.

At the very least, this would make it much easier for an admin to set up
symlinks in a Windows CVS repository.  They could just create shortcuts
from Windows Explorer.



reply via email to

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