Alright, I found the bug. The test fails when it tries to open the directory for the actual file (I think).
/tmp/cvs-sanity/cvsrootdir/123456789012345678901234567890/123456789012345678 901234567890/123456789012345678901234567890/123456789012345678901234567890/1 23456789012345678901234567890/123456789012345678901234567890/123456789012345 678901234567890/123456789012345678901234567890/12345678901234567890123456789 0/123456789012345678901234567890/file1,v rcs.c (2055) *pfp = CVS_FOPEN (rcs->path, FOPEN_BINARY_READ); *pfp is NULL and errno is set to ENOENT (no such file or dir). rcs->path contains the directory path only. Is that as intended? fopen is right, there is no such directory visible. However, the symlink "/tmp/cvs-sanity/cvsrootdir/second-dir/fileX,v" works and the real file (as above) exists. Hm ... I agree, sounds strange but that's how it is. I've seen this behaviour before created by cvs (but even ftp and some other unix utilities) both in Interix and CygWin. It is just not possible navigate to this directory. We managed to create a file system error somehow. Actually, I would say quite serious bug no matter whose fault it is. Do CygWin pass the tests? One possible reason could be that cvs ultimately are using ASCII/ANSI versions of the system API file I/O functions. Since Windows NT is UNICODE based, these functions are limited in e.g. buffer sizes. For complicated things the real functions are a much better choice, but of course completely unportable. I need help. Where, when and how is this directory created? _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
