.exe handling change in fileutils-4.1-2

.exe handling change in fileutils-4.1-2

[Doru Carastan]

In reply to: http://cygwin.com/ml/cygwin/2003-11/msg00478.html
--------------------------------------------------------------

It is normal to see "touch foo.exe; cp foo bar" fail. You just created 
foo.exe, which is definitely not foo. Check with "ls -l".

The current versions of autoconf and automake define and use 
EXEEXT=.exe. Check your Makefile.am or Makefile.in files and add 
$(EXEEXT) to all commands that involve executables.

Good luck,

Doru Carastan
------------------------------------------------------------
Cygwin Contractor    doru.c @ pacbell.net
San Jose, CA            http://www.4jobs.com/DoruCarastan


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: .exe handling change in fileutils-4.1-2

[Nathan J. Williams]

Doru Carastan <doru.carastan@mvista.com> writes:

> In reply to: http://cygwin.com/ml/cygwin/2003-11/msg00478.html
> --------------------------------------------------------------
> 
> It is normal to see "touch foo.exe; cp foo bar" fail. You just created
> foo.exe, which is definitely not foo. Check with "ls -l".

Yes, I'm aware that foo.exe is not foo, but fileutils-4.1-1 contained
code which special-cased this situation, IMO very usefully. What I
would like to see is a ChangeLog entry or CVS log message or something
that corresponds to and explains the removal of that code.

> The current versions of autoconf and automake define and use
> EXEEXT=.exe. Check your Makefile.am or Makefile.in files and add
> $(EXEEXT) to all commands that involve executables.

The build system in question is not based on autoconf/automake.

        - Nathan

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

.exe handling change in fileutils-4.1-2

[Nathan J. Williams]

I recently installed a fresh version of Cygwin on a machine and had my
build system fail, due to the previously discussed issue with cp and
.exe files. In a nutshell, "touch foo.exe; cp foo bar" fails. See:

http://cygwin.com/ml/cygwin/2003-10/msg00989.html
http://cygwin.com/ml/cygwin/2003-09/msg01196.html

I tracked it down to the removal of a block of code between
fileutils-4.1-1 and fileutils-4.1.2:

--- fileutils-4.1-1/./src/copy.c	2001-06-15 15:20:08.000000000 -0400
+++ fileutils-4.1-2/./src/copy.c	2001-06-25 18:42:46.000000000 -0400
@@ -197,25 +197,6 @@
   source_desc = open (src_path, O_RDONLY);
   if (source_desc < 0)
     {
-#ifdef __CYGWIN__
-      char *p;
-      if ((p = strchr (src_path, '\0') - 4) <= src_path || strcasecmp (p, ".exe") != 0)
-	{
-	  p = alloca (strlen (src_path) + 5);
-	  src_path = strcat (strcpy (p, src_path), ".exe");
-	  source_desc = open (src_path, O_RDONLY);
-	  if (source_desc >= 0)
-	    {
-	      if ((p = strchr (dst_path, '\0') - 4) <= dst_path ||
-		  (p[-1] != '.' && strcasecmp (p, ".exe") != 0 ))
-		{
-		  p = alloca (strlen (dst_path) + 5);
-		  dst_path = strcat (strcpy (p, dst_path), ".exe");
-		}
-	      goto ok;
-	    }
-	}
-#endif /*__CYGWIN__*/
       /* If SRC_PATH doesn't exist, then chances are good that the
 	 user did something like this `cp --backup foo foo': and foo
 	 existed to start with, but copy_internal renamed DST_PATH
@@ -229,9 +210,6 @@
       return -1;
     }
 
-#ifdef __CYGWIN__
- ok:
-#endif
   /* These semantics are required for cp.
      The if-block will be taken in move_mode.  */
   if (*new_dst)
@@ -1163,16 +1141,6 @@
     {
       if (chmod (dst_path, get_dest_mode (x, src_mode)))
 	{
-#ifdef __CYGWIN__
-	char *p;
-	if ((p = strchr (dst_path, '\0') - 4) <= src_path || strcasecmp (p, ".exe") != 0)
-	  {
-	    p = alloca (strlen (dst_path) + 5);
-	    (void) strcat (strcpy (p, src_path), ".exe");
-	    if (chmod (p, src_mode & x->umask_kill) == 0)
-	      goto ok;
-	  }
-#endif /*__CYGWIN__*/
 	  error (0, errno, _("setting permissions for %s"), quote (dst_path));
 	  if (x->set_mode || x->require_preserve)
 	    return 1;


This code was added in 4.1-1 in the first place, with the rationale
that it's good for make(1) rules. I found this to be true. I've
searched for a comment or rationale for removing this, but I haven't
found a Cygwin-specific ChangeLog for fileutils, nor CVS for it, nor
even an announcement of 4.1-2 (did it ride in with Cygwin 1.5.0-1 or
1.5.1-1?).

Was this an intentional change? If so, what was the intent? The
previous behavior is very useful.

        - Nathan


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/