pombreda / libarchive

Automatically exported from code.google.com/p/libarchive
Other
0 stars 0 forks source link

Simple text files interpreted as mtree #399

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a file with content this content (a single line without quotes):
  "b704c67b39978aff8cc254e78976f001ea07a6d0"
2. Open the archive using format all|raw
3. Run archive_read_next_header() on ther archive

What is the expected output? What do you see instead?

Expected:
Get the plain entry, reported as "data", format "raw"

Instead:
ERROR: Missing type keyword in mtree specification

What version are you using?

3.1.2

On what operating system?

Ubuntu

How did you build?  (cmake, configure, or pre-packaged binary)

pre-packaged

What compiler or development environment (please include version)?

Please provide any additional information below.

According to mtree(5), mtree files must start with
"#mtree".  How can it be that the file is misinterpreted?

Original issue reported on code.google.com by JanWiele...@gmail.com on 4 Feb 2015 at 3:02

GoogleCodeExporter commented 9 years ago
mtree(5) is wrong.  There is no required header text.

That said, it should be possible to improve the mtree bidder to reject files 
that are obviously missing required text.

Mixing raw + mtree is a particularly risky combination, since it is very hard 
to distinguish mtree from plain text files.   I generally recommend that people 
not mix raw with any other format handler except 'empty.'

Original comment by kientzle@gmail.com on 5 Feb 2015 at 5:00

GoogleCodeExporter commented 9 years ago
I've started to put together a test that tries to verify that the mtree bidder 
is doing the right thing.

Please take a look at the attached file and see if these cases all make sense.  
If you can think of other cases that would help us to fine-tune the mtree bid 
logic, please let us know.

Note:  The current code gets most of these right, but not all.

Original comment by kientzle@gmail.com on 22 Feb 2015 at 8:16

Attachments: