2

I have an unarchiver that takes in an archive name, and a directory name, and dumps all files from that archive into that directory. No other command-line options. However, someone zipped a file in the archive I am looking to decompress, with 500-ish characters in the filename, and now that program fails when it hits that file (practically all file systems have a limit of 256). What alternative do I have, short of changing the source code and recompiling the unarchiver?

I must mount something as a directory, which would take the files that the unarchiver is writing, and dump them elsewhere – possibly even as one big file. This something should not send fail messages, even if some write really did fail.

I have tried mounting a directory as a file – however, that directory must have an underlying filesystem, and then it has the same limitations as the original FS.

I have also tried using a pipe – but a pipe cannot have arguments after it (e.g. /pipe/reallylongfilename). Is something like this possible?

The archive is a .zim. I am using the zimdump tool from the OpenZim library.

Improve this question
3
  • The name length limit might come from the common kernel code, not even any filesystem-specific parts. Otherwise you could use FUSE (on Linux) to do something like you're describing. But it may just be easier to fix the archiver to do shorten extra-long names, or just binary patch the archive to make the name more sensible. I do wonder how the archive was created, though. The list in wikipedia doesn't have many filesystems that would support file names > 255 bytes/characters. Commented Jun 28, 2017 at 15:08
  • what is the archive format? May be possible to find another unarchiver tool that can support renaming output. Commented Jun 28, 2017 at 15:42
  • You may consider changing the title. Your real problem is the overly long filename in the archive and the title should reflect this. Compare: XY problem. The question is OK (no XY syndrome there), I'm talking about the title. Commented Jun 28, 2017 at 17:39

1 Answer 1

Reset to default
2

If you know this very long name then you can try to edit it inside the archive using hex editor (or sed?). Work with a copy in case you need to start from scratch.

Let the example filename be very-long-filename. Reasonable angles of attack:

  • very/long/filename,
  • very//////filename,
  • very0long-filename where 0 indicates NULL character (0x00),
  • very00000000000000 (0 as above).

In general it's not wise to delete characters (thus making the archive smaller). It changes important offsets inside the archive and will probably corrupt it.

I made a test with a .zip file. I admit my very-long-filename was not too long. I managed to make it shorter and maybe these methods will also work for names that are too long. In my test I had to edit two fragments of the file because every filename in .zip was stored twice.

You used the word "zipped" but didn't state clearly what your archive is. Whatever it is I hope it stores filenames in plain text and you will succeed in editing them. Good luck.

Improve this answer
4
  • It's in the comments. .zim file. I'll give it a try. Commented Jun 28, 2017 at 17:33
  • It looked like there were extra characters after the filename, which signify that the filename is over-- but I figured it out. Thanks-- I never realized that even the most compressed archives could still contain plaintext filenames... Commented Jun 29, 2017 at 22:01
  • @Alex Thanks for your feedback. It's good to know you solved the problem. Commented Jun 29, 2017 at 22:08
  • FYI ZIP format has a header (immediately) before each file/entry, plus a collected clump of headers for all files/entries traditionally called the 'central directory' even though it's at the end: en.wikipedia.org/wiki/Zip_%28file_format%29#Structure Commented Jun 30, 2017 at 7:34

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.