phingofficial/phing

Copy task does overwrite even though overwrite="false" (Trac #605)

phing-issues-importer opened this issue · 15 comments

If the source file is touched (i.e. mtime changed) then phing copyTask will overwrite destination no matter thay overwrite="false" is set. This is very unexpected.

Migrated from https://www.phing.info/trac/ticket/605

{
    "status": "new", 
    "changetime": "2015-04-19T07:48:44", 
    "description": "If the source file is touched (i.e. mtime changed) then phing copyTask will overwrite destination no matter thay overwrite=\"false\" is set. This is very unexpected.", 
    "reporter": "Denis Chmel", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1429429724464363", 
    "component": "phing-core", 
    "summary": "Copy task does overwrite even though overwrite=\"false\"", 
    "priority": "minor", 
    "keywords": "", 
    "version": "2.4.1", 
    "time": "2010-12-08T13:14:07", 
    "milestone": "Backlog", 
    "owner": "mrook", 
    "type": "defect"
}

Trac update at 20101208T13:21:23: mrook commented:

Please try using the latest Phing version.

Trac update at 20101210T09:07:09: Denis Chmel commented:

2.4.4 - the same.

Trac update at 20110112T14:54:31: mrook commented:

What OS and PHP version do you have installed? Can you provide a build file with a test case?

Trac update at 20110125T12:53:38: Denis Chmel commented:

Here you are:

php -v

PHP 5.3.4-0.dotdeb.0 with Suhosin-Patch (cli) (built: Jan  3 2011 19:56:59)

cat /etc/issue && uname -a

Debian GNU/Linux 5.0 \n \l

Linux dev 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC 2010 i686 GNU/Linux

build.xml

<?xml version="1.0" encoding="UTF-8"?>
<project name="test" basedir="." default="install">

  <target name="install">
    <copy file="config.yml.sample" tofile="config.yml" overwrite="false"/>
  </target>

</project>

test.sh

rm -f config.yml* > /dev/null
echo "one" > config.yml.sample
phing
sleep 1
echo "two" > config.yml.sample
phing
test "`cat config.yml`" = "one" || echo "Test failed"

Trac update at 20110209T22:02:44: mrook changed milestone from "TBD" to "2.4.5"

Trac update at 20110209T22:40:01:

  • mrook commented:

Upon reflection (now that I understand your use case better), changing the behavior of the copy task would be a backwards compatible break. The way copy behaves currently mimics the corresponding Ant task. When "overwrite" is "false", target files that are older than their source counterparts will be replaced. Setting "overwrite" to "true" means that all files will be replaced.

Because of the BC-issue I'm moving this one back to the TBD queue, so everybody can argue this issue before I make a decision.

  • mrook changed milestone from "2.4.5" to "TBD"

Trac update at 20110210T16:24:11: Denis Chmel commented:

I see. Thanks for explaining.

Then it could be either additional parameter (e.g. "neveroverwrite", which will underline ambiguity of Ant's param as well :) or a new task (e.g. ). Looking forward for your solution.

Trac update at 20110224T12:15:35: Denis Chmel commented:

The workaround is to touch destination file (w/o creating) before copy:

  <target name="install">
    <exec command="touch --no-create config.yml"/>
    <copy file="config.yml.sample" tofile="config.yml" overwrite="false"/>
  </target>

Trac update at 20120315T10:36:00: mrook changed milestone from "TBD" to "2.4.11"

Trac update at 20120720T13:49:46: Michiel Rook commented:

Refs #538 - clarify the overwrite attribute
Changeset: bf4f00f

Trac update at 20121016T13:53:26: mrook changed milestone from "2.4.13" to "2.4.14"

Trac update at 20140201T12:36:10: mrook changed milestone from "2.7.0" to "2.8.0"

Trac update at 20140825T12:30:31: Niek Oost commented:

When you want to overwrite a file that has just been created by a script, touch won't help. In such a case you need to remove the file prior to copying:

<target name="install">
  <exec command="rm config.yml"/>
  <copy file="config.yml.sample" tofile="config.yml" overwrite="false"/>
</target>

Trac update at 20150419T07:48:44: mrook changed milestone from "2.11" to "Backlog"

The documentation describes this behavior now bf4f00f - feel free to reopen this ticket, if there is something missing