Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix error truncating non-existing file, fix truncating to invalid (unintialized) file length. #10

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

KickerTom
Copy link

If there are no chunks, truncate is called on nonexistent file, and throws exception.
Also, the defaults in the constructor mean the getLength will return nonsense, thus truncate will be called with invalid (negative) length, again throwing exception.
Tested on H85010e_00_OPEN_EU_OP_0817.kdz file.

@ehem
Copy link
Owner

ehem commented Nov 19, 2016

A link to the file would have been helpful. LG certainly appears to be doing some interesting things with the KDZ files for the G5.

The defaults in the constructor were meant to flag that we didn't really know much about the slice and things were going to need to be fixed. I feel those defaults should remain since as here they successfully flagged a circumstance which isn't really supposed to happen. Using the length specified by the chunk isn't really appropriate since that merely indicates the block ranges the chunk is supposed to overwrite.

The exception though does need to be avoided, for which the obvious flag is finding that self.getLength() is less than 0. If there are no chunks that merely means the KDZ doesn't overwrite any portion of the slice, in which case my thinking was having an empty file was an appropriate flag. Truncating a file to a length greater than its existing length though is perfectly legal, even Windows handles this situation appropriately (or so I've read). The result is a "sparse" file which appears to be the specified length, but doesn't take any data blocks.

The big problem is the G5 (and presumably other Qualcomm 82x devices) has its on-board flash presented as several physical devices. ie instead of /dev/mmcblk0p{0-56}, it has /dev/sd[a-e]. Each of the /dev/sd[a-e] devices has its own GPT, so undz.py needs to be modified to expect the need to handle multiple GPTs. Then there is the mysterious OP/OP_T slice where they're doing really interesting things.

@KickerTom
Copy link
Author

Thanks for the extensive description. You know the format much better than me (my only source of information is your wiki here on github, which is unfortunatelly quite sparse. BTW, are there some better descriptions around?), so I am sure my fix was bad :-). G5 really is different, even unkdz.py is complainig (there are unreferenced data after the header, looks like some manifest, or directory).
I just needed to extract the dz file so I can create twrp flashable zip (and that worked fine with my changes). I will keep investigating, as time permits, maybe I will find out more.

@ehem
Copy link
Owner

ehem commented Nov 23, 2016

Yeah, the wiki is quite sparse. My main goal was to state what the various fields mean and it isn't really much more than a copy of a few lines out of dz.py. Major problem at this point is the unknowns in the header.

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.

2 participants