DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:from:date:message-id:subject:to
	:content-type; q=dns; s=default; b=YWqT2Sl821M9VtE6yQ8E2gNxpp88B
	+UBcTa8Kl8i6if/nScZO0b6bLjqy45zUxx6Rt/VuJZqMttlniZeYZbAPk8CjGvuo
	gtzRavIzCQ40ZCLxAPlYZpeUQ7S62a51GFVoZpcuu0IoWlTkbsYsn3FhW4lQSOFs
	TCv85cYv+wQw0k=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
MIME-Version: 1.0
From: Dan Kegel <dank AT kegel DOT com>
Date: Mon, 8 Oct 2018 14:24:35 -0700
Message-ID: <CAPF-yObTngOGu_+TSfSQo4bpi_tJ3572r_26cfidLZ5QpcPGYQ@mail.gmail.com>
Subject: Fun with cp -R error when both foo and foo.exe exist
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset="UTF-8"

Everybody who uses cygwin knows that if foo and foo.exe exist, you can do
  cp foo bar
  cp foo.exe bar.exe
but not
  cp foo.exe bar.exe
  cp foo bar
because of the unavoidable magic in cygwin that lets you execute foo
when you really mean foo.exe.

Well, it just bit me again during a buildbot try build of electron.
Here's the scenario:

 argv: ['git', '--version']
 argv: ['rm', '-rf',
'/home/buildbot/slave-state/electron-oblong-1-7-x-try-win10/build']
 argv: ['git', 'fetch', '-t', 'git AT gitlab DOT foo DOT com:platform/electron.git']
 argv: ['git', 'fetch', '-t',
'git AT gitlab DOT foo DOT com:jisorce/electron.git', 'window_infos']
 argv: ['git', 'reset', '--hard', 'FETCH_HEAD', '--']
 argv: ['git', 'checkout', '-B', 'window_infos']
 argv: ['git', 'submodule', 'sync']
 argv: ['git', 'submodule', 'update', '--init', '--recursive',
'--force', '--checkout']
 argv: ['cp', '-R', '-P', '-p', '-v',
'/home/buildbot/slave-state/electron-oblong-1-7-x-try-win10/source',
'/home/buildbot/slave-state/electron-oblong-1-7-x-try-win10/build']
cp: cannot create regular file
'/home/buildbot/slave-state/electron-oblong-1-7-x-try-win10/build/vendor/libchromiumcontent/vendor/depot_tools/ninja':
File exists

Maybe the order of files reported via the system call cp uses to
expand a directory was unfortunate after that git operation.

The workaround was to nuke the source directory, thus forcing a clean
checkout.  (And alas that means I don't have the directory to inspect
anymore.)

A nice workaround might be for the cygwin version of cp could arrange
to wait to create .exe files until after any potential non-suffixed
file has been processed... not sure how easy that would be.

Apologies if this has already been discussed.
- Dan

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