sub-directories as file names

[sonnenscheinchen]

compress-tools v0.13.0, libarchive v3.6.1

Example archive:
http://ftp.uni-erlangen.de/mirrors/aminet/demo/aga/Hardcore.lha

Test:

use compress_tools::*;
use std::fs::File;
use std::path::Path;

fn main() -> Result<()> {
    let mut source = File::open("Hardcore.lha")?;
    let dest = Path::new("/tmp/dest");
    uncompress_archive(&mut source, dest, Ownership::Ignore)?;
    Ok(())
}

Current result:
File "035.SDM" in root directory named "sdm-hardcore\datas\035.SDM"

$ ls /tmp/dest/
 File_Id.Diz   Hardcore.readme   sdm-hardcore  'sdm-hardcore\datas\035.SDM'

Expected result:
File "035.SDM" in directory "sdm-hardcore/datas"

$ ls /tmp/dest/
 File_Id.Diz   Hardcore.readme   sdm-hardcore  

[otavio]

Was this working before 0.12.4 release?

[otavio]

Ok, so I did few tests:

1. reproduced using 0.12.3 release
2. reproduced using 0.13.0 release
3. checked it works using bsdtar

So this is indeed a issue with this create. Now, we need to find why.

[sonnenscheinchen]

Found another one:
http://ftp.uni-erlangen.de/mirrors/aminet/demo/aga/FLP-TTD.lha

I tested with 7z, lha (lhasa),the delharc crate and various gui apps using libarchive. Everything is fine. It is strange that only some files fail in this particular way and not all. A mystery. :-)

[otavio]

Not a mistery, it has different path separator. See:

[src/lib.rs:259] target_path = "t/sdm-hardcore/datas/034.SDM"
[src/lib.rs:259] target_path = "t/sdm-hardcore\\datas\\035.SDM"
[src/lib.rs:259] target_path = "t/sdm-hardcore/datas/036.SDM"

[otavio]

I am trying to understand why it isn't splitting the Components.

[otavio]

I got the debug output using following patch:

diff --git a/src/lib.rs b/src/lib.rs
index 0db45a9..5649de8 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -256,6 +256,8 @@ where
                 )
                 .unwrap();
 
+                dbg!(&target_path);
+
                 ffi::archive_entry_set_pathname(entry, target_path.as_ptr());
 
                 let link_name = ffi::archive_entry_hardlink(entry);

[otavio]

It seems the core issue is the Path handling in Rust. See following example: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a2dc0880eb9be5b30156b9d206cd0d1b

[sonnenscheinchen]

Not a mistery, it has different path separator.

Hm, then the problem is somewhere else (earlier?) because every path in the archive is separated by a single backslash.
See:

$ strings Hardcore.lha | grep datas

[...]
sdm-hardcore\datas\034.SDM
sdm-hardcore\datas\035.SDM     <---- this!
sdm-hardcore\datas\036.SDM
[...]

Still a mystery. :-)

[otavio]

Unsure. Here it shows a different path for 035.SDM. I suspect you are using Windows?

[sonnenscheinchen]

Here it shows a different path for 035.SDM.

Where ever this comes from, it's not correct.
I checked with the "stings" command from binutils and a hex-editor. They usually don't lie. :-) Definitely single 0x5C (according LHA spec).

I suspect you are using Windows?

No, I use Arch Linux.

[otavio]

On list, it shows fine. On extract it fails.

[cgzones]

This seems to be fixed (by accident) with e9637bf.

Until a buffer size of 6005 it fails, with a size of 6006 or bigger it works.

Probably a libarchive internal bug? (Although running against libarchive build with ASAN and UBSAN reports no issues.)

[otavio]

Please add a CHANGES item mentioning this. We could then cut a release :-)

[cgzones]

There seems to be an issue with side effects of archive_read_data_block() at

compress-tools-rs/src/lib.rs

Line 569 in c08486c

match ffi::archive_read_data_block(archive_reader, &mut buffer, &mut size, &mut offset)

, cause commenting out

compress-tools-rs/src/lib.rs

Line 276 in c08486c

libarchive_copy_data(archive_reader, archive_writer)?;

produces the correct path (but obviously only NUL data).