ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Ludwig <>
Subject Re: Delete task eagerness on Windows
Date Mon, 20 Apr 2009 20:13:11 GMT schrieb am 20.04.2009 um 06:49:04 (+0200):
> > 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.

> > 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.

> 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)

Moin Jan,

this may be a JVM issue, indeed; but Ant aggravates it considerably by
applying recursion.

The doc for "public boolean" says:

| Deletes the file or directory denoted by this abstract pathname.
| If this pathname denotes a directory, then the directory must be
| empty in order to be deleted.

Write-protection is not mentioned here, and indeed disregarded.
I think this can be considered a horrible bug.

The JVM has no problems setting write-protection.


public class SetReadOnly {
  public static void main( String[] args) throws IOException {
    if ( args.length < 1 ) {
      System.err.println( "Argumente!");
    for ( String arg : args ) {
      File f = new File( arg);
      if ( ! f.createNewFile() ) {
        System.err.format( "Kann %s nicht anlegen!%n", f);
      if ( ! f.setReadOnly() ) {
        System.err.format( "Kann %s nicht schreibschuetzen!%n", f);

java SetReadOnly a b c
attrib /s

But then it gets quite hilarious, and could get quite tragical.


public class ReadOnlyOrMaybeNot {
  public static void main( String[] args) throws IOException {
    if ( args.length < 1 ) {
      System.err.println( "Argumente!");
    for ( String arg : args ) {
      File f = new File( arg);
      System.err.format( "%s - canWrite() ? %s%n", f, f.canWrite());
      System.err.format( "%s - delete() ? %s%n", f, f.delete());
      System.err.format( "%s - exists() ? %s%n", f, f.exists());

java ReadOnlyOrMaybeNot a b c
a - canWrite() ? false
a - delete() ? true
a - exists() ? false
b - canWrite() ? false
b - delete() ? true
b - exists() ? false
c - canWrite() ? false
c - delete() ? true
c - exists() ? false

So, yes, the files are write-protected, but no, it doesn't matter.

Tested with Sun jdk1.6.0_11, jdk1.6.0_07 and jre1.5.0_09.

I made a slight modification to my Ant script to create a file inside
the folder to see if that prevents Ant from erasing it.

more >
<project name="DeleteTest" basedir="C:/temp/DeleteTest"
  <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}"/>
    <!-- Put a file in so File#delete() on the folder will fail. -->
    <echo message="Moin" file="${test.dir}/moin.txt"/>
  <target name="clean">
    <delete file="${test.file}"/>
    <delete dir="${test.dir}"/>

Then a shell for cmd.exe to test the behaviour.

more > readonly.cmd
@echo off
set ANT_OPTS=-showversion
set ANT_ARGS=-v
call ant -v -f ant-delete-2.xml
set test_dir=C:\temp\DeleteTest
pushd %test_dir%
attrib /s /d +R
attrib /s /d
call ant -v -f ant-delete-2.xml clean
echo on
dir /s /b %test_dir%
@echo off
echo Alles futsch ...

So what Ant does seems to be a recursive and unconditional application
of what I think is a horrible JVM/Windows bug.

Which I hope Larry Ellison is going to fix now!

Michael Ludwig

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message