[Top][All Lists]

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

Re: BUG in "cvs co -r" (CVS 1.11.0)?

From: Greg A. Woods
Subject: Re: BUG in "cvs co -r" (CVS 1.11.0)?
Date: Thu, 3 Jan 2002 14:03:17 -0500 (EST)

[ On Thursday, January 3, 2002 at 11:32:25 (-0500), Larry Jones wrote: ]
> Subject: Re: BUG in "cvs co -r" (CVS 1.11.0)?
> Alexei Lioubimov writes:
> > 
> > cvs [checkout aborted]: cannot open directory .../CVS/mypoj/Attic: Not a
> > directory
> > 
> > It is true -- since i have deleted nothing in myproj yet, i don't have Attic
> > in it. But why is it impossible to checkout a tag or revision if module
> > doesn't contain Attics?
> > 
> > After i manually mkdir _empty_ Attic in .../CVS/mypoj cvs was satisfied and
> > checked out mytag.
> > Is this a BUG? If yes, then is there a workaround?
> It would appear to be a bug in your operating system.  CVS expects an
> attempt to open a non-existent directory to return an ENOENT error, not
> an ENOTDIR error.  What system is this happening on?  And is your
> repository on a local disk or some kind of network file system?

ENOTDIR will be the result if you try to chdir() to a regular file, for
example, or if an intermediate directory in a pathname turns out to be a
anything but a directory file.  This should be true on any kind of
system.  From chdir(2) on *BSD:

     [ENOTDIR]     The file descriptor does not reference a directory.

Also from intro(2) on *BSD:

     20 ENOTDIR Not a directory.  A component of the specified pathname
                existed, but it was not a directory, when a directory
                was expected.

Yes, ENOENT means the directory does not exist, but it's not safe to
assume that ENOENT will be the only error returned when trying to do
some operation on a directory.

So, therefore the first and most important question to ask Alexei is
whether or not there was some other filesystem object called "Attic"
before the manual mkdir of the new empty Attic directory.  Only if not
then could there may be a bug in the OS.

I'm guessing the error above comes from this segment of code in

        /* search the attic too */
        if (which & W_ATTIC)
            char *dir;
            dir = xmalloc (strlen (repository) + sizeof (CVSATTIC) + 10);
            (void) sprintf (dir, "%s/%s", repository, CVSATTIC);
            if (find_rcs (dir, files) != 0
                && !existence_error (errno))
                /* For now keep this a fatal error, seems less useful
                   for access control than the case above.  */
                error (1, errno, "cannot open directory %s", dir);
            free (dir);

existence_error() is defined with this rather ugly but no doubt more
portable mess:

/* Not all systems set the same error code on a non-existent-file
   error.  This tries to ask the question somewhat portably.
   On systems that don't have ENOTEXIST, this should behave just like
   x == ENOENT.  "x" is probably errno, of course. */

#  ifdef EOS2ERR
#    define existence_error(x) \
     (((x) == ENOTEXIST) || ((x) == ENOENT) || ((x) == EOS2ERR))
#  else
#    define existence_error(x) \
     (((x) == ENOTEXIST) || ((x) == ENOENT))
#  endif
#  ifdef EVMSERR
#     define existence_error(x) \
((x) == ENOENT || (x) == EINVAL || (x) == EVMSERR)
#  else
#    define existence_error(x) ((x) == ENOENT)
#  endif

(why can't POSIX-compatible systems stick to the basics in basic
situations like this?!?!?!??!  having to go to such lengths for the sake
of POSIX portability is stupid)

The function find_rcs(), also in find_names.c, could return an error
either when it tries to CVS_OPENDIR(".../CVS/mypoj/Attic"), or perhaps
if either CVS_READDIR() or CVS_FNMATCH() fails.  On no normal system
will either ever return ENOTDIR though, so only the CVS_OPENDIR() call
is a likely candidate for causing this error.  On most systems opendir()
calls open(2), which says:

     [ENOTDIR]     A component of the path prefix is not a directory.

suggesting again that the thing called "Attic" was not a directory in
Alexei's repository (until after it was manually made to be one).

If not then Alexei's operating system does have a serious bug or is at
least not very POSIX compatible.

In any case I cannot duplicate the error on a *BSD system.

                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

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