TWRP's effectively bugged split backups

TWRP has definitely revolutionalized Android’s recovery battlefield, with all touch GUI and several other new features to the field. Lately, there has been some debate going on about the changing trend of TWRP’s recent versions. I am, however, not to continue this debate, but rather to “argue” about one feature which, in my opinion, is effectively bugged and not the best choice.

TWRP, just like CWM and some other recoveries, does split tar balls for partitions larger than 2GB, since FAT and FAT32 has a limit of 2GB for a single file size. This, in practice is a wonderful idea without which most newer devices, with their large data partitions, would be unable to survive a nandroid backup. Now, let’s look at how this is implemented by CWM and TWRP.

In CWM, it just splits the tar ball into several blocks of 1GB each. These chunks are not full tar balls themselves, but need to be joined consecutively, in the order they were split, in order to form a full tar ball. CWM pipes these individual chunks to tar while restoring. This guarantees one very important point of the idea of split backups. Each chunk file is exacly 1GB, irrespective of file sizes inside the tar ball.

In TWRP, this works differently. My best guess is that they have deliberately tried to be different from CWM, which is acceptable and would be better, given that it does not break functionality of the idea behind splitting backup files.

TWRP creates a list of files, with 1 file in excess of 1GB and creates a tar ball of the list of files. Unlike CWM’s split chunks, these are comlete tar balls. This process continues until all the files in the specific partition are backed up. If the list gets over 2GB, TWRP warns that the filesystem contains a file over 2GB and thus the backup might not restore properly. There is a chance that a single file in a file system can be over 2GB. Some might argue that this is just theoratical, but in today’s Android world where app sizes are touching the skies, it is very much practical. There are even some apps that I know of, whose sizes are well over 2GB. In such a case, at least one of the split tar balls would be over 2GB. TWRP would definitely emit an error stating that it might not restore properly, but this is of no help for the user. The user does not have any other way of performing a proper nandroid backup which would properly restore, except perhaps going for TWRP’s competition.

Some might argue that the individual backup files should be complete tar balls, which can be readable and editable by users, rather than chunks of a full tar balls, which are not readable and not editable, unless joined together. My argument is that nandroid backup files are not meant to be edited by users and if they are to be read or edited, the user or software should also possess the resorces and knowledge of how to joing the individual chunks.

To conclude things, TWRP has tried to be different from the competition and also make individual split files readable, both of which are good ideas but failed and defeats the original purpose behind split backups.

I urge the TWRP team to take this to drawing board again and re-think about it. I am not asking to do it the same way as CWM and other competitive recoveries, but to do it in a more practical way which fulfills the original purpose of split backups, ie; split file sizes not being over 2GB AT ANY COST.

At times, developers (read, human beings) make wrong decisions in the development cycle. Winners are those who do not fear to change the wrong decisions made by them.