I have not heard much on this list from the original developers in a while. While it is possible that they monitor this list, they might be too busy with other things...
I have also been able to reproduce this issue in a unit test. The basic problem is that VFS caches all file information (if you look at the code, it is all the "attached" business). If you delete a file outside of VFS, VFS's file information is not updated, which leads to the problem you discovered. The message thread pointed to by the original message does address one way of dealing with this but this does not help from Ant. There are different solutions to look into. But first, the obvious: 1) Use the VFS v-delete task instead of plain delete. http://jakarta.apache.org/commons/sandbox/vfs/anttasks.html#V-Delete 2) Tweak the VFS ant task such that mixing VFS and non-VFS tasks can be mixed. I do not know if this is possible. 3) Tweak VFS itself to be able to toggle cacheing on and off. This could be a big effort, I am not sure. Try (1) first. Gary > -----Original Message----- > From: Jacob Kjome [mailto:[EMAIL PROTECTED] > Sent: Friday, December 26, 2003 19:07 > To: Jakarta Commons Users List > Subject: RE: [vfs] problem with multiple Ant <v-copy>'s to the same > filename > > 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:[EMAIL PROTECTED] > > > Sent: Monday, December 22, 2003 11:05 > > > To: [EMAIL PROTECTED] > > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
