RE: [vfs] problem with multiple Ant 's to the same filename

[Jacob Kjome <ho...@visi.com>]

Sure glad someone is actually interested in VFS.

Here's a minimized testcase.  The issue seems to be with doing <v-copy>, 
<delete>, and another <v-copy> where the file being copied to is the same 
name.  <v-copy> reports that the deleted file exists and is read-only 
rather than recognizing that the file was deleted.  If no delete is done in 
between, then it works fine.

<project name="test" default="test-vfs" basedir=".">

      <target name="test-vfs">
         <taskdef resource="org/apache/commons/vfs/tasks/tasks.properties"/>

         <v-copy 
src="http://archive.apache.org/dist/jakarta/commons/cli/binaries/cli-1.0.tar.gz"
                 destfile="file.tar.gz"/>
         <delete file="file.tar.gz"/>
         <v-copy 
src="http://archive.apache.org/dist/jakarta/commons/codec/binaries/commons-codec-1.2.tar.gz"
                 destfile="file.tar.gz"/>
         <delete file="file.tar.gz"/>
     </target>

</project>

I get the following when I run under Ant-1.6.0...

D:\myclasses\Repository\Jakarta>ant -f vfstest.xml
Buildfile: vfstest.xml

test-vfs:
    [v-copy] Copying 
http://archive.apache.org/dist/jakarta/commons/cli/binaries/cli-1.0.tar.gz 
to file://D:/myclasses/Repository/Jakarta/file.tar.gz
    [delete] Deleting: D:\myclasses\Repository\Jakarta\file.tar.gz
    [v-copy] Copying 
http://archive.apache.org/dist/jakarta/commons/codec/binaries/commons-codec-1.2.tar.gz 
to file://D:/myclasses/Repository/Jakarta/file.tar.gz


BUILD FAILED
D:\myclasses\Repository\Jakarta\vfstest.xml:10: Could not copy file 
"http://archive.apache.org/dist/jakarta/commons/codec/binaries/commons-codec-1.2.tar.gz" 
to
"file://D:/myclasses/Repository/Jakarta/file.tar.gz" because the 
destination file is read-only.


I'd love to have this fixed because it fits my needs perfectly....except 
for the dependency on commons-logging.  That's really annoying.  It messes 
up log4j logging if log4j.jar and log4j.xml exist in the build and 
commons-logging exists in ANT_HOME/lib since commons-logging can't see 
either log4j.xml or log4j.jar.  This means I'll have to build the classpath 
for the VFS tasks locally for each app since having commons-logging in 
ANT_HOME/lib will mess up log4j logging in every build I use.  Anyway, 
that's a separate issue that I doubt will be resolved to my satisfaction 
since so many (all?) commons components depend on commons-logging, so this 
comment is really more of a mini bitch session than a bug report which you 
can safely ignore.  Made me feel better, though.

Jake

At 06:39 PM 12/26/2003 -0500, you wrote:
>Hello,
>
>I've tried to duplicate a simple version of this problem in a unit test in
>but could not simulate this problem (See
>ProviderWriteTests.testOverwriteSameFileSystem method in CVS or the next
>build). Perhaps you could provide a standalone test case?
>
>Thanks,
>Gary
>
>PS: I am not one of the original developers of VFS but we are planning on
>using VFS here at work, so have been looking at the innards and fixed one or
>two very minor things.
>
> > -----Original Message-----
> > From: Jacob Kjome [mailto:hoju@visi.com]
> > Sent: Monday, December 22, 2003 11:05
> > To: commons-user@jakarta.apache.org
> > Subject: [vfs] problem with multiple Ant <v-copy>'s to the same filename
> >
> > I'm using the <v-copy> task to download files from http and ftp sites.
> > This
> > seems to work find, except that if I have multiple <v-copy> tasks copying
> > to
> > the same destfile (which gets deleted after each run, BTW), I get the
> > following
> > error...
> >
> >      [echo] /java/repository/commons-beanutils-1.6.1/commons-beanutils.jar
> > [vfs:v-copy] Copying
> > http://archive.apache.org/dist/jakarta/commons/beanutils/bi
> > naries/commons-beanutils-1.6.1.tar.gz to file://C:/java/repository/aFile
> >    [gunzip] Expanding C:\java\repository\aFile to
> > C:\java\repository\aFile.tar
> >     [untar] Expanding: C:\java\repository\aFile.tar into
> > C:\java\repository
> >    [delete] Deleting: C:\java\repository\aFile.tar
> >    [delete] Deleting: C:\java\repository\aFile
> >      [echo] /java/repository/commons-collections-2.1/commons-
> > collections.jar
> > [vfs:v-copy] Copying
> > http://archive.apache.org/dist/jakarta/commons/collections/
> > binaries/collections-2.1.tar.gz to file://C:/java/repository/aFile
> >
> > BUILD FAILED
> > C:\myclasses\repository\TheHartford\CEII\NBS\build.xml:373: Following
> > error occu
> > red while executing this line
> > C:\myclasses\repository\TheHartford\CEII\NBS\utility-targets.incl:187:
> > Could not
> >  copy file
> > "http://archive.apache.org/dist/jakarta/commons/collections/binaries/
> > collections-2.1.tar.gz" to "file://C:/java/repository/aFile" because the
> > destina
> > tion file is read-only.
> >
> >
> > The destination file "aFile" is deleted, so why is <v-copy> reporting it
> > to be
> > existing and, apparently, "read-only"?  Does it have something to do with
> > the "caching" problem reported at this thread?
> > http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=106786840807527&w=2
> >
> > If I run Ant again, then it can download the file it failed on before, but
> > then
> > it craps out again if it has to download another.  So, essentially, If I
> > have
> > 20 files to download, I have to run the Ant build 20 times to get all the
> > files.  That't obviously a bug.  Is this a known issue?  Is it going to be
> > fixed soon?
> >
> > The VFS tasks seem awesome, but I can't use them given this current bug.
> > Can
> > it be fixed soon?
> >
> > Jake
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org


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