Problem with built-in path normalization

[timsueberkrueb]

I have a use case where I need to create a debian-like package format.
In a nutshell, I have to create a tar file with the following entries structure:

/./
- /./manifest
- /./control

where the root entry is indeed named .

Is there a way to create this (valid) tar file with tar-rs?
I tried different ways but failed.

What I expected to work was the following:

fn create_tar_gz(filepath: &Path, dir: &Path) -> io::Result<()> {
    let archive = std::fs::File::create(filepath)?;
    let enc = GzEncoder::new(archive, Compression::default());
    let mut tar = tar::Builder::new(enc);
    tar.append_dir_all("./.", dir)?;
    tar.finish()?;
    Ok(())

However, it creates a tar file with the following structure:

manifest
control
/./
- empty entry directory

... because the current dir component gets stripped away here:

tar-rs/src/header.rs

Line 1502 in 60c6bd8

(Component::CurDir, false) => continue,

Just changing this line to:

            (Component::CurDir, false) => {},

fixes the problem.

I have the following questions:

1. Is there a way to create the desired tar file with the current API provided by tar-rs?
2. If no, would a contribution be accepted for making it work and if so, what would the requirements for that be/how should that look like?

Thanks!

[mfrischknecht]

I've just run into a similar problem myself, so I'm glad there's already a ticket for this.

However, I've got a question on your proposed change:
From my cursory glance at the code, this change would also allow paths such as ./foo/./bar. Is that correct?

As set_path() is documented like this:

Will strip out any "." path component, which signifies the current directory.

...I'd assume that this isn't desired behavior. Wouldn't be something like this more desirable?

    for (position, component) in path.components().enumerate() {
        //...
        match (component, is_link_name) {
            //...
            // Allow paths starting with "./"
            (Component::CurDir, false) if position == 0 => {}
            (Component::CurDir, false) => continue,
            //...
        };
        //...
    }

[timsueberkrueb]

However, I've got a question on your proposed change:

That's correct. This is not a fix I propose for inclusion in this library, this is just a quick demonstration/allowing me to continue working on my project.

Wouldn't be something like this more desirable?

Yeah, this is where I think we need input from the library authors. It becomes inconsistent with the claim that . components get stripped away either way.

We could also:

• stop stripping away .'s in paths entirely and leave that to the user
• add an option for that to Builder similar to Builder::follow_symlinks.

depending on whether or not breaking changes are a concern or not.