ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scot P. Floess" <sflo...@nc.rr.com>
Subject RE: Problem with zip task
Date Tue, 28 Jul 2009 18:29:17 GMT

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:groodt@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.cole@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:sfloess@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-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>> For additional commands, e-mail: user-help@ant.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@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-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message