does not "preservelastmodified" on directories.

[Cyril Sagan <cy...@gmail.com>]

My goal is to copy a directory tree, and preserve the last-modified-time of
all the files and *directories* in the copied tree.

Through my research through the Ant manual, mailing lists, and bug database
I find no mention of this being possible, or reported previously as an
enhancement request.   My workaround is to <exec/> "cp -pR".   This works
fine on our Unix flavors, but does not work on Windows.

I glanced at the code for org.apache.tools.ant.util.FileUtils and
ResourceUtils, from the source it doesn't look like the preservelastmodified
attribute was ever intended to apply to directories.    Can someone from
ant-dev offer an opinion on why directories aren't (shouldn't be?) included
in the semantics for preserving modification times?

Does this seems like a reasonable enhancement request?
Can anyone suggest a Windows workaround?

Thanks.

--Cyril

Re: does not "preservelastmodified" on directories.

[Steve Amerige <St...@sas.com>]

Hi Stefan,

Thanks for the super-rapid reply.  I'll try a couple of approaches and report back what seems to do the best job.  It might just be 
that using <exec> (in a switch statement catering for all desired operating systems) is the only way to get exact timestamps, ACLs, etc.

Again thanks!
Steve Amerige
SAS Institute, Deployment Software Development

On 10/18/2011 7:17 AM, Stefan Bodewig wrote:
> On 2011-10-18, Steve Amerige wrote:
>
>> I'm wondering if the<zip>  task might get you what you're looking for.
>> Although, I'm baffled over the the statement that "Zip archives store
>> file modification times with a granularity of two seconds."  You're
>> kidding, right?  :-)
> Not at all, that's the format definition.
>
> Some implementations use extra field data to store timestamps at a
> different granularity (or other time stamps like creation time or last
> access time) but they are ignored in most cases.
>
>> The<tar>  task doesn't mention the 2-second granularity problem, but
>> even with<tarfileset>,
> TAR uses a one second granularity (seconds since midnight Jan 1st 1970,
> "the epoch"), the same is true for CPIO or AR if you wanted to use the
> Compress Antlib.
>
> tar is likely faster than zip as well as it won't compress the files.
>
>> the documentation seems to imply that it damages the modes (see the
>> filemode and dirmode attributes).
> Ant can not read the current file permissions (not possible without
> native code pre-Java7) and thus cannot tell zip/tar what to store.
>
> The same limitation applies to copy itself, Ant's copy task doesn't
> preserve permissions either.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
>

Re: does not "preservelastmodified" on directories.

[Stefan Bodewig <bo...@apache.org>]

On 2011-10-18, Steve Amerige wrote:

> I'm wondering if the <zip> task might get you what you're looking for.
> Although, I'm baffled over the the statement that "Zip archives store
> file modification times with a granularity of two seconds."  You're
> kidding, right?  :-)

Not at all, that's the format definition.

Some implementations use extra field data to store timestamps at a
different granularity (or other time stamps like creation time or last
access time) but they are ignored in most cases.

> The <tar> task doesn't mention the 2-second granularity problem, but
> even with <tarfileset>,

TAR uses a one second granularity (seconds since midnight Jan 1st 1970,
"the epoch"), the same is true for CPIO or AR if you wanted to use the
Compress Antlib.

tar is likely faster than zip as well as it won't compress the files.

> the documentation seems to imply that it damages the modes (see the
> filemode and dirmode attributes).

Ant can not read the current file permissions (not possible without
native code pre-Java7) and thus cannot tell zip/tar what to store.

The same limitation applies to copy itself, Ant's copy task doesn't
preserve permissions either.

Stefan

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

Re: does not "preservelastmodified" on directories.

[Steve Amerige <St...@sas.com>]

Hi Cyril and all,

I'm wondering if the <zip> task might get you what you're looking for.  Although, I'm baffled over the the statement that "Zip 
archives store file modification times with a granularity of two seconds."  You're kidding, right?  :-)  The roundup attribute 
doesn't fix this issue, it just changes the badness from one form to another.

The <tar> task doesn't mention the 2-second granularity problem, but even with <tarfileset>, the documentation seems to imply that 
it damages the modes (see the filemode and dirmode attributes).

When I get a chance, I'll test these.

Enjoy,
Steve Amerige
SAS Institute, Deployment Software Development

On 10/13/2011 11:55 PM, Stefan Bodewig wrote:
> On 2011-10-13, Cyril Sagan wrote:
>
>> I glanced at the code for org.apache.tools.ant.util.FileUtils and
>> ResourceUtils, from the source it doesn't look like the preservelastmodified
>> attribute was ever intended to apply to directories.    Can someone from
>> ant-dev offer an opinion on why directories aren't (shouldn't be?) included
>> in the semantics for preserving modification times?
> Because you are the first person who ever cared about the last modified
> times of directories, or at least the first person who ever spoke up.
> Really.  It just never occured to us.
>
>> Does this seems like a reasonable enhancement request?
> Yes.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
>
>
>

Re: does not "preservelastmodified" on directories.

[Stefan Bodewig <bo...@apache.org>]

On 2011-10-13, Cyril Sagan wrote:

> I glanced at the code for org.apache.tools.ant.util.FileUtils and
> ResourceUtils, from the source it doesn't look like the preservelastmodified
> attribute was ever intended to apply to directories.    Can someone from
> ant-dev offer an opinion on why directories aren't (shouldn't be?) included
> in the semantics for preserving modification times?

Because you are the first person who ever cared about the last modified
times of directories, or at least the first person who ever spoke up.
Really.  It just never occured to us.

> Does this seems like a reasonable enhancement request?

Yes.

Stefan

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