Skip to content

Conversation

@ovidiul
Copy link

@ovidiul ovidiul commented Mar 13, 2017

No description provided.

ovidiul added 15 commits March 1, 2017 10:53
fixing directory size to match zero on TAR archives FileInfo
FileInfo code display fix
When adding a file which size is being changed during archiving, the archive would become corrupt because the size in the header is different than the size of the actual data written. So an additional check should be done and if the sizes are different, the header should be updated. A quick test would be to create a loop where you write 1 byte to a test.txt file and then trying to add that file to the archive and extracting the archive.
When adding a file which size is being changed during archiving, the archive would become corrupt because the size in the header is different than the size of the actual data written. So an additional check should be done and if the sizes are different, the header should be updated. A quick test would be to create a loop where you write 1 byte to a test.txt file and then trying to add that file to the archive and extracting the archive.
@ovidiul ovidiul mentioned this pull request Mar 13, 2017
Copy link
Owner

@splitbrain splitbrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not comfortable merging this until I fully understand what the x header is doing.

}
}

/**
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indentation seem wrong again. please make sure you use 4 spaces for indentation. not tabs!

$filename = trim($this->readbytes(ceil($return['size'] / 512) * 512));
// next block is the real header
$block = $this->readbytes(512);
$return = $this->parseHeader($block);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand. You are not using the data read from x header. $filename is never used. You basically just read and ignore the x header.

Since your tests work, I assume the original header already contains the proper UTF-8 filename? Would a very long UTF-8 filename have an x and an L header?

@splitbrain
Copy link
Owner

Looking at the IBM document you provided in #18 an x header will contain key value pairs. I dumped the header from your files and that confirms it:

28 path=./4слайд.jpg
20 ctime=1489408528
20 atime=1489408285
23 SCHILY.dev=16777220
23 SCHILY.ino=53836974
18 SCHILY.nlink=1

So for implementing it correctly, the path key in this header should overwrite the filename from the standard header.

The header may also contain a charset key which would give all other data (including path) in that charset. We would probably need to call iconv or mbstring on that then.

Ideally we should also create such a header when adding UTF-8 filenames.

@splitbrain
Copy link
Owner

@ovidiul any updates on this?

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

Successfully merging this pull request may close these issues.

3 participants