RE: CVS update: /ccvs/lib/

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> 
> >Log:
> > * 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. 

I added "lib/lstat.c" because linker didn't have definition for external
symbol "_rpl_lstat" and a grep found only 1 definition.  I had seen this
commit to "windows-NT/config.h" files:
https://ccvs.cvshome.org/servlets/ReadMsg?list=cvs&msgNo=3881
which I assume meant the reference to "rpl_lstat" was intentional.

I've always assumed commits to "windows-NT" config files reflected a well
considered plan so I often don't examine the committed changes other than
noting the file names.  I now see room for process improvement.  What are
your thoughts?

> 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
> #endif
> 
> I think window-NT/filesubr.h will need to include "lstat.h" after this
> change as well.

A good suggestion.  I'll work on it and have it committed by Sunday.

> 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.

I like the idea.  Windows shortcuts can do more than UNIX symbolic links
besides linking to files and folders.  I'll look into how shortcuts are
exposed at the native API level.

> Regards,

Ditto,

> Derek

Conrad