Out of interest, are archive.dir and staging.dir on the same filesystem?
On Tue, Jul 28, 2009 at 7:29 PM, Scot P. Floess <sflo...@nc.rr.com> wrote:
>
> I suppose if nothing else maybe exclude all .nfs* files from your
> fileset???
>
>
> On Tue, 28 Jul 2009, Cole, Derek E wrote:
>
> Could this be something that is happening because zip, or some task,
>> creates a temporary file...then that process dies, leaving the unlinked file
>> out there. And for whatever reason, the next time the zip task is run, it is
>> able to see this file but...can't get to it?
>> When I am on the linux box the build is actually running from, I never can
>> see any of these .nfs files..but this is the second time in two days this
>> has happened to us. Usually we re-run the build, and it is successful the
>> next time.
>>
>> Derek
>>
>> -----Original Message-----
>> From: Cole, Derek E
>> Sent: Tuesday, July 28, 2009 2:11 PM
>> To: Ant Users List
>> Subject: RE: Problem with zip task
>>
>> I am not sure what is considered relevant...here is the target that is
>> being run...
>>
>> <target name="archive" depends="stage" description="creates an archive
>> containing all projects's resources and build artifacts.">
>> <property name="archive.dir" value="${project.dir}"/>
>> <mkdir dir="${archive.dir}"/>
>>
>> <zip destfile="${archive.dir}/${archive.name}" encoding="UTF8"
>> whenempty="create">
>> <fileset dir="${staging.dir}"/>
>> </zip>
>>
>> </target>
>>
>>
>> In the build log, it says right before the [zip] out put
>>
>> [mkdir] Skipping /path-to/..../archivedir because it already exists
>>
>> And post-build failure I checked to make sure that staging.dir actually
>> existed as well
>>
>>
>>
>>
>> -----Original Message-----
>> From: Greg Roodt [mailto:gro...@gmail.com]
>> Sent: Tuesday, July 28, 2009 2:04 PM
>> To: Ant Users List
>> Subject: Re: Problem with zip task
>>
>> Hmmmm, looks a bit suspicious. Could you please include the relevant parts
>> of the build.xml?
>>
>> I know that a few Java File operations dont work very well across file
>> systems. Renaming has given me problems in the past.
>>
>>
>>
>> On Tue, Jul 28, 2009 at 6:58 PM, Cole, Derek E <derek.e.c...@lmco.com
>> >wrote:
>>
>> The mounts are persistent, and we are not doing anything like that as
>>> part of the build.
>>>
>>>
>>> I did find some information on the .nfs files:
>>>
>>>
>>> .nfs files are created by a clienthost when one process on the
>>> clienthost deletes a file while another process on the clienthost is
>>> still holding the file open. This allows the delete to appear to
>>> succeed for one process w/o causing the the process to begin getting
>>> stale nfs file handles. It is a hack, but it is the only way to
>>> simulate UFS semantics on NFS. The clienthost will normally delete the
>>> .nfs file once the remaining process holding the file open closes
>>> it. However, if the clienthost crashes, you get left with a .nfs file
>>> on the filer.
>>>
>>>
>>> Note that if more than one host is involved (e.g, process on host a is
>>> holding a file open over NFS, while process on host b deletes that
>>> over NFS), process a will get a stale file handle.
>>>
>>>
>>> Could something like this be happening as part of a simple zip task?
>>>
>>>
>>> -----Original Message-----
>>> From: Scot P. Floess [mailto:sflo...@nc.rr.com]
>>> Sent: Tuesday, July 28, 2009 1:56 PM
>>> To: Ant Users List
>>> Subject: Re: Problem with zip task
>>>
>>>
>>> Interesting looks like an nfs issue... Are you automounting or
>>> anything?
>>>
>>> On Tue, 28 Jul 2009, Cole, Derek E wrote:
>>>
>>> Has anyone encountered a problem when running a zip task, the log will
>>>> say something like
>>>>
>>>> [zip] Building zip: /path-to/some.war
>>>>
>>>> [zip] adding directory ........
>>>>
>>>>
>>>>
>>>> Then getting an exception that says
>>>>
>>>>
>>>>
>>>> Problem creating zip:
>>>> /path-to/someotherdir/.nfs0000000000000001a121a00000003ae (No such
>>>>
>>> file
>>>
>>>> or directory)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The way the problem is listed..doesnt that seem like a problem with a
>>>> network storage access? /path-to/ is a mount to a NAS
>>>>
>>>>
>>>>
>>> Scot P. Floess
>>> 27 Lake Royale
>>> Louisburg, NC 27549
>>>
>>> 252-478-8087 (Home)
>>> 919-890-8117 (Work)
>>>
>>> Chief Architect JPlate http://sourceforge.net/projects/jplate
>>> Chief Architect JavaPIM http://sourceforge.net/projects/javapim
>>>
>>> Architect Keros http://sourceforge.net/projects/keros
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
>>> For additional commands, e-mail: user-h...@ant.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
>>> For additional commands, e-mail: user-h...@ant.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
>> For additional commands, e-mail: user-h...@ant.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
>> For additional commands, e-mail: user-h...@ant.apache.org
>>
>>
>>
> Scot P. Floess
> 27 Lake Royale
> Louisburg, NC 27549
>
> 252-478-8087 (Home)
> 919-890-8117 (Work)
>
> Chief Architect JPlate http://sourceforge.net/projects/jplate
> Chief Architect JavaPIM http://sourceforge.net/projects/javapim
>
> Architect Keros http://sourceforge.net/projects/keros
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
>
>
