Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Confusing error with append_path_with_name and named pipes #356

Open
Cerber-Ursi opened this issue Apr 4, 2024 · 0 comments
Open

Confusing error with append_path_with_name and named pipes #356

Cerber-Ursi opened this issue Apr 4, 2024 · 0 comments

Comments

@Cerber-Ursi
Copy link

Summary

When:

  • user uses append_path_with_name,
  • with "path" argument being absolute path of a named pipe,
  • and "name" argument being valid relative path,

tar returns an error which doesn't seem to make any sense.

Reproduction

Checked on Linux, probably could be reproduced in a similar way on other Unix systems.

Setup

cargo new append_path_pipe_error
cd append_path_pipe_error
cargo add tar
mkfifo pipe
touch file

main.rs:

fn main() {
    let mut tar = tar::Builder::new(vec![]);
    let base_path = std::env::current_dir().unwrap();

    let mut append = move |name| {
        tar.append_path_with_name(base_path.join(name), name)
            .expect(name);
    };

    append("file"); // works
    append("pipe"); // breaks
}
cargo run

Expected

Either one of two:

  • Code returns an error saying something about named pipes (or file types in general, like it does when archiving named pipes on non-Unix).
  • Code completes successfully.

Actual

Code returns the following error:

Custom { kind: Other, error: "paths in archives must be relative when setting path for " }

...which doesn't show the problematic path (it's empty when the error is generated) and names the problem that, from consumer's point of view, shouldn't arise at all (the in-archive path is relative, after all).

Possible reason

A little code-digging led me to this block, which calls append_special using only the source path, but ignoring the target one (i.e. name). I'm not sure whether this reasoning is correct and what could break if we simply replace path with name (hence an issue and not PR), but will be happy to help in testing if this is indeed the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant