ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Jan.Mate...@rzf.fin-nrw.de>
Subject AW: Delete task eagerness on Windows
Date Mon, 20 Apr 2009 04:49:04 GMT
> Ant (version 1.7.1), or more precisely: Ant's Delete task merrily
> deletes write-protected files and directories on Windows XP 
> that cannot
> be deleted using the DEL (without /f) and RD commands from the cmd.exe
> console.
> 
> In cmd.exe, type:
> 
> more > ant-delete.xml
> <project name="DeleteTest" basedir="C:/temp/DeleteTest"
> default="create">
>         <property name="test.dir" location="abc"/>
>         <property name="test.file" location="abc.txt"/>
>         <target name="create">
>                 <echo message="Moin" file="${test.file}"/>
>                 <mkdir dir="${test.dir}"/>
>         </target>
>         <target name="clean">
>                 <delete file="${test.file}"/>
>                 <delete dir="${test.dir}"/>
>         </target>
> </project>
> ^Z (hit <F6>)
> 
> rem Create project folder
> md C:\temp\DeleteTest
> 
> rem Create file and folder
> ant -f ant-delete.xml
> 
> rem Set write-protection
> attrib +R C:\temp\DeleteTest
> attrib +R C:\temp\DeleteTest\abc
> attrib +R C:\temp\DeleteTest\abc.txt
> 
> rem Try to delete using RD and DEL, which fails
> rd C:\temp\DeleteTest\abc
> del C:\temp\DeleteTest\abc.txt
> 
> rem But Ant unscrupulously cleans up ...
> ant -f ant-delete.xml clean
> 
> Now abc and abc.txt are gone, despite being write-protected. I find it
> difficult to consider this a feature. Is this behaviour intentional?
> 
> Note that as a consequence, <delete dir="${some.dir}"/> on 
> Windows means
> to recursively and unconditionally remove ${some.dir}, which even on
> UNIX would require the user to spell out `rm -rf'.
> 
> Note that on UNIX, a `chmod a-w' on the project folder prevents Ant
> from deleting file and folder.


Searching ...

The main parts are in <taskdef> (Delete.java)
http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools
/ant/taskdefs/Delete.java
    private boolean delete(File f) {
        if (!FILE_UTILS.tryHardToDelete(f)) {
            if (deleteOnExit) {
                int level = quiet ? Project.MSG_VERBOSE :
Project.MSG_INFO;
                log("Failed to delete " + f + ", calling deleteOnExit."
                    + " This attempts to delete the file when the Ant
jvm"
                    + " has exited and might not succeed.", level);
                f.deleteOnExit();
                return true;
            }
            return false;
        }
        return true;
    }

http://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools
/ant/util/FileUtils.java
    /**
     * Accommodate Windows bug encountered in both Sun and IBM JDKs.
     * Others possible. If the delete does not work, call System.gc(),
     * wait a little and try again.
     *
     * @return whether deletion was successful
     * @since Ant 1.8.0
     */
    public boolean tryHardToDelete(File f) {
        if (!f.delete()) {
            if (ON_WINDOWS) {
                System.gc();
            }
            try {
                Thread.sleep(DELETE_RETRY_SLEEP_MILLIS);
            } catch (InterruptedException ex) {
                // Ignore Exception
            }
            return f.delete();
        }
        return true;
    }


So basically the task tries one or two time the deletion via the JVM.
According to that I would think that the ignorance of the read-only
attribute is inside the JVM.

Could you try deleting the file via another Java application eg
NetBeans/Eclipse? (Running on the same
VM)


Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message