golift / xtractr Goto Github PK

I'm filing this here as the problem is with the xtractr, but it's realized when using your unpackerr.

When the extractor checks to see if the SearchPath is empty, if it errors out while checking, it assumes the path is empty and deletes it. You should check for an error condition and print out a warning instead of deleting.

Logs:

2022/08/05 10:39:09 Error: Reading path '/media/downloads/complete/sonarr/Some.Folder': lstat /media/downloads/complete/sonarr/Some.Folder/Some.File.mkv: input/output error
2022/08/05 10:39:09 Deleted (recursively): /media/downloads/complete/sonarr/Some.Folder
2022/08/05 10:38:17 Extraction Started: Some.Folder, items in queue: 0
2022/08/05 10:39:09 Deleted (recursively): /media/downloads/complete/sonarr/Some.Folder_unpackerred
2022/08/05 10:39:09 Extraction Finished: Some.Folder => elapsed: 52s, archives: 1, extra archives: 0, files extracted: 1, wrote: 3030MiB

Make sure we do not recurse into ISO files. That's probably not wanted. Unpackerr/unpackerr#232

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update golangci/golangci-lint-action action to v6

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Hello,

I had an issue with unpackerr due to one of the *Arrs where an archive was mislabelled as RAR, but it was in fact a 7z archive. This is easily identified using the file command: file actually_7z.rar. Archives generally have magic numbers to identify their type more reliably, I think this is a less brittle method.

I have scenarios where the total length of the file paths being extracted are too long for the system's maximum path length. Mostly with naming from languages outside of english. Anyway, before I make a PR, I was wondering if there is something I'm missing in the code that can supress this error or ideally can handle it properly?

Again, I am looking at the code and it doesn't look like it but, I can be blind sometimes, so I figured I'd ask before I start a PR.

And for the sake of clarity and example, I a check like this in rar.go:

func MaxPathLength ...
	// find the max path length based on the system and return it
   // or, if that's annoying, then just set the max to a const with some sane limit that works for all systems 

func (x *XFile) unrar(rarReader *rardecode.ReadCloser) (int64, []string, error) {
    ...
    for {
        header, err := rarReader.Next()
		...

        wfile := x.clean(header.Name)
        
        if len(wfile) > MaxPathLength() {
            // Skip the file with some warning or something...
            log.Warnf("Skipping file with long path: %s", wfile)
            continue

            // Or, what woiuld be even better is truncate the file name somehow inside the archive...
        }

    }
}

Your library came in as a life saver for me, so thank you for your work! 👍

PS: if I do a PR, I'm thinking a handler for this so the user can handle the logic for dealing with it but I'm open to whatever you think would be best for your package.

DeleteOrig only deletes the first archive file and not the entire group.

Make response can receive the current progress.

Just a suggestion I don't think this is definitely a good feature and may cause performance issues. But it would be a good feature to be able to choose whether to restore the current progress.

Add support for these where possible and reasonable:

• lz4 .lz4
• brotli .br
• snappy .sz
• xz .xz
• zlib .zz
• compress/lzw .Z
• zstandard .zst
• lzh .lzh, .lha (not ready)
• lzx .lzx (three parts, needs a detector?)
• ar .deb
• rpm .rpm
• cpio .cpio
• asar .asar
• cab .cab
• lzma .lzma .lz .lzip
• arj arj (requested but no library exists)

Include additional extensions we may be missing, especially for the variants of compression+tar.