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 _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs