commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-328) TarArchiveEntry preserveLeadingSlashes has no effect on setName
Date Thu, 07 Jan 2016 21:23:39 GMT


Torsten Curdt commented on COMPRESS-328:

In {{jdeb}} we are basically transforming {{TarArchiveEntry}}'s and we need to make sure that
the resulting {{TarArchiveEntry}} is consistent in regards to the leading slash. Of course
we could just rip out the private {{normalizeFileName}} method and guard the name in the {{jdeb}}
code base - but besides the ugly code duplication it raises the question what {{preserveLeadingSlashes}}
means when being passed to the constructor.

Always preserve? Why is there only one way to preserve - on the constructor?

See my point?

IMO it's more than unlikely that the need to preserve or not to preserve the slash changes
across the lifetime of a {{TarArchiveEntry}} instance - which is why I am (in theory) in favor
of my presented change of a read-only property. That said - Emmanuel's suggestion is better
in terms of backwards compatibility (although I doubt this would affect many people). And
it might be a little awkward that {{setName()}} might give the same result when reading back
with {{getName()}}.

Then again - maybe the normalization should not be part of {{TarArchiveEntry}} at all.

> TarArchiveEntry preserveLeadingSlashes has no effect on setName
> ---------------------------------------------------------------
>                 Key: COMPRESS-328
>                 URL:
>             Project: Commons Compress
>          Issue Type: Improvement
>            Reporter: Torsten Curdt
>            Priority: Minor
> We've run into an inconsistency with the TarArchiveEntry at jdeb.
> You can create a `TarArchiveEntry(String name, boolean preserveLeadingSlashes)` but the
`preserveLeadingSlashes` is only applied in the constructor.
> I am proposing to turn `preserveLeadingSlashes` into a read-only property and use the
value on `setName()`, too (instead of just false).
> This has some implications and maybe some backwards compatibility issues - but even then
I think it would be the right thing to do.
> I am happy to make the change but thought to discuss this first.

This message was sent by Atlassian JIRA

View raw message