commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [compress] TarArchiveEntry and Windows drive letter
Date Fri, 05 Jan 2018 12:28:55 GMT
> >    TarArchiveEntry("C:\foo\bar") -> "/foo/bar"
> >    TarArchiveEntry("D:\foo\bar") -> "/foo/bar"
> "strip the drive letter" predates preserveLeadingSlashes

Might be but I guess the only question is how to fix it without breaking
too many things.
I am not such a big fan of "preserveLeadingSlashes" either.

I could be convinced that we should only strip drive letters when we
> don't preserve leading slashes either :-)

IMO there is just no case at all when compress should strip drive letters.
Sure it might be convenient (for some) but this is too much magic.

Usually tar archives do not contain absolute path names at all.

Which is also why the current constructors have a huge potential of
ambiguity and misinterpretation IMO.

  TarArchiveEntry(File file)
  TarArchiveEntry(File file, String fileName)
  TarArchiveEntry(String name)
  TarArchiveEntry(String name, boolean preserveLeadingSlashes)
  TarArchiveEntry(String name, byte linkFlag)
  TarArchiveEntry(String name, byte linkFlag, boolean

If it should be relative and you pass a File - relative to what?
If I pass in a string there should be no need for "preserveLeadingSlashes"
it should be just that string.

Just some random thoughts.

Maybe worth cleaning up that part of the API.

> Is that in line with how other unix tool ports handle things on windows?
> No idea, really.

It might be worth checking with Windows users to see what the expected
behaviour might be.
But even then - I still think silently stripping is the wrong thing to do.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message