You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Plamen Totev <pl...@gmail.com> on 2018/01/11 18:47:23 UTC
Re: plexus-archiver / plexus-util Issue
Hi,
On 12/28/2017 10:16 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> On 28/12/17 20:46, Stephen Connolly wrote:
>> But shouldn’t we be copying the last modified time stamp always anyway
>
> I'm the same opinion...but that means in consequence that the test in
> plexus-archiver is not correct...cause it's waiting for a change in the
> last-modified time ...
>
> Hm...
>
> Kind regards
> Karl Heinz Marbaise
>
>
Plexus Archiver tests are using file copy operation to change the
"last modified" timestamp of a file. This of course is not a perfect
approach but I don't think there was better one pre-Java 7. But now as
Java 7 is the minimum required version, there is
Files#setLastModifiedTime that does better job. I've created a PR that
changes the incompatible code[1]. It will allow the update of Plexus
Utils to 3.1.0 as well.
> After I have changed that and only use
>
> public static File copy( File source, File target )
> throws IOException
> {
> Path copy = Files.copy( source.toPath(), target.toPath(),
> StandardCopyOption.REPLACE_EXISTING,
> LinkOption.NOFOLLOW_LINKS );
> return copy.toFile();
> }
>
> it looks like working (see branch issue-fix):
>
> What Do you think?
The Plexus Archiver tests were not using `copy` for its intended
purpose so the decision if the file attributes are copied should not
be based on their usage. To me it makes more sense to copy the
attributes, although copying the last modified timestamp may surprise
some evelopers (like me for example) as `cp` on Linux updates the last
modified timestamp of the copy.
Regards,
Plamen Totev
[1] https://github.com/codehaus-plexus/plexus-archiver/pull/77
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: plexus-archiver / plexus-util Issue
Posted by Stephen Connolly <st...@gmail.com>.
On Thu 11 Jan 2018 at 18:47, Plamen Totev <pl...@gmail.com> wrote:
> Hi,
>
> On 12/28/2017 10:16 PM, Karl Heinz Marbaise wrote:
> > Hi,
> >
> > On 28/12/17 20:46, Stephen Connolly wrote:
> >> But shouldn’t we be copying the last modified time stamp always anyway
> >
> > I'm the same opinion...but that means in consequence that the test in
> > plexus-archiver is not correct...cause it's waiting for a change in the
> > last-modified time ...
> >
> > Hm...
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
>
> Plexus Archiver tests are using file copy operation to change the
> "last modified" timestamp of a file. This of course is not a perfect
> approach but I don't think there was better one pre-Java 7. But now as
> Java 7 is the minimum required version, there is
> Files#setLastModifiedTime that does better job. I've created a PR that
> changes the incompatible code[1]. It will allow the update of Plexus
> Utils to 3.1.0 as well.
>
> > After I have changed that and only use
> >
> > public static File copy( File source, File target )
> > throws IOException
> > {
> > Path copy = Files.copy( source.toPath(), target.toPath(),
> > StandardCopyOption.REPLACE_EXISTING,
> > LinkOption.NOFOLLOW_LINKS );
> > return copy.toFile();
> > }
> >
> > it looks like working (see branch issue-fix):
> >
> > What Do you think?
>
> The Plexus Archiver tests were not using `copy` for its intended
> purpose so the decision if the file attributes are copied should not
> be based on their usage. To me it makes more sense to copy the
> attributes, although copying the last modified timestamp may surprise
> some evelopers (like me for example) as `cp` on Linux updates the last
> modified timestamp of the copy.
Ahh but extraction from an archive should preserve the archive time stamp...
And dir-to-dir copy is really just archive-unarchive without the
intermediate archive file ;-)
>
> Regards,
> Plamen Totev
>
> [1] https://github.com/codehaus-plexus/plexus-archiver/pull/77
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone