RE: cp error -- oh the great sanity of *nix tools?!?

[Glen Coakley <gcoakley at mqsoftware dot com>]

I thought this thread would have died by now. VERY recently there was a
discussion about cp and that exact same error message. There was two points
that came out of that. One was that there cp would give that error if you
attempted to copy an executable w/o specifying the .exe (such as the way
most *nix systems would since they don't use .exe). The second, thanks to
somebody on this list digging into the source code was that, cp displayed
the wrong error message if errno was above 112 (or something like that). 

With my apologies Soren, I would have to check the mailing list archives in
order to find the exact messages. But, since I am not having a problem with
this I will refer you to them. There are enough keywords in the above
paragraph that you should not  have any problem finding the relegated
messages by searching the archives. If you don't know where to find the
mailing list archive, I would look on the site that you found cygwin.

________________________________
Glen Coakley, Sr. Software Engineer
MQSoftware Inc., (763) 543-4845


> -----Original Message-----
> From: Soren Andersen [mailto:soren@wonderstorm.com]
> Sent: Monday, June 25, 2001 2:30 PM
> To: cygwin@cygwin.com
> Subject: Re: cp error -- oh the great sanity of *nix tools?!?
> 
> 
> The estimable Randall R Schulz <rrschulz@cris.com> responded 
> Re: cp error --
> oh the great sanity of *nix tools?!?
> 
> 
> > Perhaps those two files _were_ the same. Namely, if make's current
> > directory was /usr/sbin at time the cp commands were invoked.
> 
> I was not. I made sure of that in the Makefile script,  even 
> had it print
> out where it was to make sure.
> 
> > I don't believe cp reports that the source and destination 
> files are the
> > same unless they are. Surely you would rather it do this 
> than open the
> > destination with the create and truncate options and then 
> copy the source
> > (now empty) to it?
> > Same as on any Unix, Linux, BSD, FreeBSD, AIX, HPUX or other Unix
> work-alike.
> 
> Ahh, as it turns out, NOT. And therein lies this GOTCHA. Read on.
> 
> And  Mac ("Michael A. Chase" <mchase@ix.netcom.com>)  also 
> wrote in his own
> reply:
> 
> >Because Cygwin mounts allow the same directory to be reachable by
> >different routes, it is not always obvious to the user whether two
> >directories or files are the same. I guess the same could be 
> true with
> >symbolic links in normal UNIXs.
> 
> I guess, if I think about it for more than 1.8 sec I begin to 
> get a headache
> .. :-).
> 
> >Please confirm what directory make was working in when it tried to
> >copy those files. The output from 'mount' is also needed to see if
> >that directory and /usr/sbin/ are really the same directory.
> 
> They are not.
> 
> OK, all those who were in nearly intolerable suspense waiting 
> for me to get
> to the answer:
> 
> It's Cygwin, AND it' s `cp'. Yep. A most unfortunate 
> interaction. To start
> with, Cygwin's gcc automatically "maps" an output executable 
> file with an
> `.exe' extension filename. That's SO helpful, yes, and might 
> usually be A
> Very Good Thing. But NOT this time.
> 
> The files I was trying to copy SIMPLY DIDN'T EXIST in the 
> directory I built
> in. Because the names came from the Makefile code, but the 
> actual files on
> disk were $(PROGS).exe, that is ... each one has .exe 
> caboosed to it ...
> because of this I had to bang my head against the proverbial 
> wall until I
> saw exactly what was in the build directory.
> 
> It IS still  `cp' s fault, too. The message is cp's utterly 
> unhelpful and
> misleading way of telling me that the source files named as command
> parameters don't exist -- and what the heck is THAT? That's a 
> bona-fide BUG
> if ever I was bitten by one. I am really astonished at this, in GNU
> software.
> 
>                           * * * * * * * * * * * * * * * * * * * *
> 
> I have a fixed Makefile.IN prepared now for this package (Berkeley DB
> 2.7.7). This software's author (SleepyCat) will I am sure *never* be
> interested in fixing his Makefile/configure setup for Cygwin, 
> because it is
> an old release. It is the highest-numbered 2.x release. I 
> chose it because
> the documentation that comes with Perl5.6.1/Cygwin says to do 
> so (to use a
> more recent bdb2.x that has the bdb1.xx-compatibility option, 
> to not break
> older Perl module code). So although it is an old package, it 
> is IMHO *not*
> irrelevent to Cygwin users (at least to those who might want 
> to compile
> their own Perl from source), since it is a Perl dependency. 
> So, who is the
> Maintainer of this sort of thing (Cygwin-Perl)? Can someone cite an
> individual to whom I could forward my fixed Makefile.IN? So 
> that it can be
> incorporated into a package to add to the existing 
> Cygwin-ported libraries?
> I had to fix some of the code, too (all only macro stuff of course).
> 
>    Regards,
>      Soren Andersen
>    Cygwin Enthusiast
> 
> > At 19:58 2001-06-24, *I* wrote:
> > >Dogma: GNU/*nix  programming is *always* so much better 
> than what Redmond
> > >can produce. Yeah, like.
> > >
> > >I am running a Makefile installation (`make install') and 
> I keep getting
> > >this error (the package is BerkeleyDB, this is irrelevent):
> > >
> > >
> > >./db_checkpoint -> /usr/sbin/db_checkpoint
> > >/usr/bin/cp: `./db_checkpoint' and 
> `/usr/sbin/db_checkpoint' are the same
> > >file
> > >./db_deadlock -> /usr/sbin/db_deadlock
> > >/usr/bin/cp: `./db_deadlock' and `/usr/sbin/db_deadlock' 
> are the same
> file
> > >./db_dump -> /usr/sbin/db_dump
> > >/usr/bin/cp: `./db_dump' and `/usr/sbin/db_dump' are the same file
> > >./db_load -> /usr/sbin/db_load
> > >/usr/bin/cp: `./db_load' and `/usr/sbin/db_load' are the same file
> > >./db_printlog -> /usr/sbin/db_printlog
> > >/usr/bin/cp: `./db_printlog' and `/usr/sbin/db_printlog' 
> are the same
> file
> > >./db_recover -> /usr/sbin/db_recover
> > >/usr/bin/cp: `./db_recover' and `/usr/sbin/db_recover' are 
> the same file
> > >./db_stat -> /usr/sbin/db_stat
> > >/usr/bin/cp: `./db_stat' and `/usr/sbin/db_stat' are the same file
> > >make: *** [install] Error 1
> > >
> > >You know, the hacker who wrote `cp' to give this error 
> wording needs to
> be
> > >put up against a wall and *shot*.
> > >
> > >What does this mean? I am sure that this is "one of those 
> things" that
> > >everybody but me and two guys in Duluth seem to know.
> > >
> > >REALLY F*%$!)($! IRRITATED,
> > >    soren andersen
> > >
> > >
> > >
> > >--
> > >Want to unsubscribe from this list?
> > >Check out: http://cygwin.com/ml/#unsubscribe-simple
> >
> >
> 
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple