extractTarFork() process ended with ERROR: 255

[dexbyte]

E: ADB Restore Failed. I had the same problem with TWRP 3.1.0 and TWRP 3.1.1 didn't fix this bug either. I am trying to restore the backup created via adb to pc. Restore always fails.

[tjanez]

I've probably encountered the same issue on my Nexus 4 with TWRP 3.1.1.

Restoring the System partition succeeds, however restoring the Data partition fails with:

I:Unable to extract tar archive '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win000'
Error during restore process.
I:Error extracting '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win000' in thread ID 0
I:Error extracting split archive.
Error during restore process.
extractTarFork() process ended with ERROR: 255

Here is the complete log output:

I:operation_start: 'Nandroid'
[RESTORE STARTED]
Restore folder: '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T'
Verifying MD5
Calculating restore details...
MD5 matched for '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/system.ext4.win'.
I:InfoManager loading from '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/system.info'.
I:Read info file, restore size is 838259712
I:split_filename: /data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win000
MD5 matched for '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win000'.
I:split_filename: /data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win001
MD5 matched for '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win001'.
I:split_filename: /data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win002
I:TWFunc::Set_Brightness: Setting brightness control to 5
MD5 matched for '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win002'.
I:InfoManager loading from '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.info'.
I:Read info file, restore size is 3867481600
MD5 matched for '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/boot.emmc.win'.
I:InfoManager file '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/boot.info' not found.
I:Restore file system is: 'emmc'.
Restoring 3 partitions...
Total restore size is 4509MB
I:Restore filename is: /data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/system.ext4.win
I:Restore file system is: 'ext4'.
I:Restore file system is: 'ext4'.
Wiping System
Formatting system using make_ext4fs...
Creating filesystem with parameters:
    Size: 880803840
    Block size: 4096
    Blocks per group: 32768
    Inodes per group: 7680
    Inode size: 256
    Journal blocks: 3360
    Label: 
    Blocks: 215040
    Block groups: 7
    Reserved block group size: 55
Created filesystem with 11/53760 inodes and 6965/215040 blocks
I:TWFunc::Set_Brightness: Setting brightness control to 0
Restoring System...
I:InfoManager loading from '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/system.info'.
I:Read info file, restore size is 838259712
I:Single archive
I:Setting archive type
I:Extracting uncompressed tar
  ==> extracting: /system//app/ (mode 40755, directory)
  [ ... output trimmed ... ]
  ==> extracting: /system//recovery-from-boot.bak (file size 83495 bytes)
I:extractTarFork() process ended with RC=0
I:Reset capabilities of /system/bin/run-as binary successful.
[System done (83 seconds)]
I:Restore filename is: /data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win
I:Restore file system is: 'ext4'.
I:Restore file system is: 'ext4'.
Wiping Data (excl. storage)
Wiping data without wiping /data/media ...
I:skipped '/data/lost+found'
I:skipped '/data/media'
I:skipped '/data/.layout_version'
Done.
I:sending message to add 65537 '/data/media/0' 'Internal Storage'
I:[MTP] mtppipe add storage 65537 '/data/media/0'
I:[MTP] MtpStorage id: 65537 path: /data/media/0
E:[MTP] MtpServer::addStorage Storage for storage ID 65537 already exists.
I:Message sent, add storage ID: 65537
Restoring Data (excl. storage)...
I:InfoManager loading from '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.info'.
I:Read info file, restore size is 3867481600
I:Multiple archives
I:First tar file '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win000' not encrypted
I:Setting archive type
I:Extracting uncompressed tar
  ==> extracting: //data/dontpanic/ (mode 40750, directory)
  ==> extracting: //data/misc/ (mode 41771, directory)
  ==> extracting: //data/misc/adb/ (mode 42750, directory)
  ==> extracting: //data/misc/adb/adb_keys (file size 2147 bytes)
  [ ... output trimmed ... ]
  ==> extracting: //data/data/com.google.android.gms/app_webview/Cache/6288c862ae5df182_0 (file size 3859 bytes)
  ==> extracting: //data/data/com.google.android.gms/app_webview/Cache/cd33a17aa6ec6eb7_0 (file size 89037 bytes)
I:Unable to extract tar archive '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win000'
Error during restore process.
I:Error extracting '/data/media/0/TWRP/BACKUPS/00867e6ad793a5eb/2017-05-21--08-51-47_LMY48T/data.ext4.win000' in thread ID 0
I:Error extracting split archive.
Error during restore process.
extractTarFork() process ended with ERROR: 255
I:Set page: 'action_complete'
I:TWFunc::Set_Brightness: Setting brightness control to 114
I:operation_end - status=1
I:Set overlay: ''
I:TWFunc::Set_Brightness: Setting brightness control to 5
I:TWFunc::Set_Brightness: Setting brightness control to 0
I:TWFunc::Set_Brightness: Setting brightness control to 114
I:Set overlay: ''
I:Set page: 'clear_vars'
I:Set page: 'restore_select'
I:Set page: 'restore'
I:Set page: 'main'
I:Set page: 'clear_vars'
I:Set page: 'main2'
I:Set page: 'advanced'
I:Set page: 'copylog'
I:Set page: 'action_page'
I:operation_start: 'Copy Log'
I:Copying file /tmp/recovery.log to /data/media/0/recovery.log

[dexbyte]

@tjanez Go to Mount and unmount the data partition then try to restore the backup, it might work. In my case, it doesn't even pass restoring the System partition.

[CP-4]

@dexbyte

[RESTORE STARTED]
Restore folder: '/data/media/0/TWRP/BACKUP/ff04fa7a/2017-........'
Skipping MD5 check based on user setting.
Calculating restore details...
Restoring 3 partitions...
Total restore size is 5746MB
Restoring Boot...
[Boot done (1 second)]
Wiping Data
Wiping data without wiping /data/media ...
Done.
Restoring Data...
extractTarFork() process ended with ERROR: 255

If i go to Mount and untick Data partition, the restore is no longer shown. It is only shown when data is mounted.

[nkk71]

@tjanez Can you hexdump the last 2048 bytes of your '/2017-05-21--08-51-47_LMY48T/data.ext4.win000' file

[CaptainThrowback]

I believe there's a fix for this issue on Gerrit, pending review: https://gerrit.omnirom.org/24146

[crok]

It has been committed at Jul 21, 2017 8:37 PM - do you know when it will be released to us?

[BuildingAtom]

I'm not sure if this is the same exact issue, but I just got back from repairing my data backup for my phone. I went through the backup with a hex editor, and it seems like information that's supposed to go to the recovery log sometimes ends up in the tar file instead. This offsets the blocks in the tar and renders it unreadable since tar expects everything to line up along 512 byte blocks.

I found the line storing xattr user.default. (hex 73 74 6F 72 69 6E 67 20 78 61 74 74 72 20 75 73 65 72 2E 64 65 66 61 75 6C 74 0A) between random blocks multiple times, and I:Closing tar. (hex 49 3A 43 6C 6F 73 69 6E 67 20 74 61 72 0A) somewhere between the last few blocks. Once I removed these with a hex editor and made sure all the tar headers lined up along the blocks, I was able to use the backup again.

I think the Gerrit fixed a different problem that could also cause the same error.

Also, when I was making this backup, I was also using MTP at the same time. Not sure if that matters.

[nkk71]

@BuildingAtom I can't say 100%, but I'm pretty sure the commit https://gerrit.omnirom.org/#/c/24146/ (merged) will fix it. I can only replicate the leaked strings if I force closing stdout, at which point the backup will show the same corruption you mentioned, and as per my initial repair commit https://gerrit.omnirom.org/#/c/23866/ Which I stopped because I didn't think it's worth updating for the extra leaked strings (as mentioned in the comments of the patchset), which cannot (easily) be done during the restore, so it would have to "clean" the file prior to restoring it. I could update it, but really don't think it's worth it, for the few corrupt backups we've seen. I did trace the error and usually the random close(fd) mentioned in the commit closes 0 (in my tests), but if it were to close(1), then you'd get the corrupt backup you mentioned. As to why only certain strings are getting leaked, it's a wild guess, but I'm thinking that the puts() are getting leaked into the tar, but the printf() are just going to nowhere instead of the tar, strange, but that's my only thought.

[BuildingAtom]

@nkk71 Ah, I see. I didn't get how the commit fixed the leaked strings at first. If puts() and printf() are doing that, that's definitely strange since afaik they should both go to the same output. Imo, adding a repair function is not worth it regardless. If the issue was fixed (which it probably was), then the corrupted backups should be cleaned outside of the recovery environment.

Also, even though the repair commit is abandoned, I can verify that storing xattr user.default. (and I assume the other strings as well) can find itself in the middle of a file, although for me it was near the end of the file, which makes some sense. I've also seen the line repeated 3 times in a row between blocks, which doesn't make sense.

I'm thinking that I might try making a separate tool to clean these files. At the very least, I'll get some more experience trying.

[nkk71]

@BuildingAtom Though all the commands are printf's, from my understanding, those will get optimized into 2 types: 1) puts when it's a simple string 2) the full printf() when there are actual variables

the latter doesn't seem to get leaked into the tar, we can confirm that from the recovery.log taken in the backup folder, all information stops after the 1st tar, and we don't even see the ending: "Thread ID %i finished successfully." in the recovery.log

I can confirm the following strings are leaked: const char *leaked_strings[] = { "I:Closing tar\n", "storing xattr user.default\n", "storing xattr user.inode_cache\n", "storing xattr user.inode_code_cache\n", NULL }; (excluding the trailing null of course)

The "Closing Tar" will be found just before the last 2x512bytes of EOF null chars (so EOF-1024-14), but the others will be randomly inserted somewhere (including possibly the file contents themselves), so stripping them isn't easy during a live restore, it can however be done for the entire file.

[BuildingAtom]

My friend and I both created our own external tools to "clean" these "corrupted" backups and tackled the problem in slightly different ways. You can find my tool CleanTwrpTar here, and my friend's tool TarCleaner here. He should be coming on relatively soon to post his tool and info.

While the tool I made is technically incomplete, it should be capable of cleaning these leaked strings from the backup files. I did make a few assumptions based on data I had such as the appearance of leaked strings occurring only along block boundaries, but I think they were relatively safe assumptions.

[venerjoel99]

@BuildingAtom has showed me this thread, and in response to this thread, he and I created our own separate tar file cleaner tools that takes out the specified leaked strings from them and produces a new clean copy of the corrupted tar file. Here is @BuildingAtom 's tool, and here is mine. For my project, I have several releases, with the newest one being the most optimized. However, some optimizations are based on assumptions that the leaked strings are between 512-byte blocks, so the first release does the most thorough search but with the slowest runtime. The runtime of the program will mostly depend on the sizes of the files these leaked strings take place at

[crok]

Thank you, @BuildingAtom and @venerjoel99! Will try the scripts!

[nkk71]

@venerjoel99 @BuildingAtom Though I haven't looked at your tools (my bad) you cannot make the assumption of the leaked strings are contained in a 512byte block, they are not, otherwise I would have pushed PS3 and be done with it a long time ago ;) (actually I do have a working version (PS4) of inline fixes but it's messy and I wouldn't push that kinda code into twrp)

You'll just need to go over the entire file in whatever block size you choose, but you'll need to overlap, ie rewind enough to make sure the lengthiest string will be properly detected.

[BuildingAtom]

@nkk71 I'm sorry, could you elaborate a bit more on that last part? From what I found, the only reason a leaked string would be within a 512 byte block and not between two blocks would be if there was already a leaked string before that string.

Because I was concerned about the rare off chance that the leaked strings might be a legitimate part of files, I tried to limit the areas where the program searched for the strings. Although I haven't exactly written it in my readme yet, my program looks for the next header location (it assumes that there's always added data) and based off of that offset, it first searches the area directly before the header, then it searches the file content of the previous header, skipping 512-byte chunks of data at a time.

Also, sorry if this is a dumb question, but what do PS3 and PS4 stand for?

[nkk71]

@BuildingAtom PS3/4 would be updated patchsets for the abandoned repair tar commit that would repair during restore, but it would have to patch in the lower level read code, and that will make a mess of libtar, which is why it was abandoned.

As for the leaked strings, the only one which can be predictably located is the I:Closing tar, whereas the other should predictable, they are not, here's an example: https://pastebin.com/EprnSGiD As you can see in this particular instance, the leaked strings are right in the middle of a file content, I'm just as confused as everyone else how this could happen as the code doesn't reflect this possibility (maybe some caching of sorts, who knows, and who knows why only some strings get sometimes leaked and other times not) According to the code (libtar/append.c), these strings should be leaked as seen in this https://pastebin.com/BEsZcpu9 which makes sense, the above paste shows however that the strings are located straight in the middle of a file_content, which isn't supposed to happen, but did.

I guess if you want to go for optimized code, you could "walk" through the tar checking both headers and making sure the file length is correct, if the file length is incorrect, then you'll have a leak within the file_content as per the first paste.

[BuildingAtom]

@nkk71 Ah, ok, PS3/4 is for patch sets. Thanks! And thanks for the elaboration. It turns out my program actually does do this, in a sense, since it calculates the expected position of the next header using the file length of the current header, then searches for it. It then looks for strings based off the offset of the next header.

For leaked strings, the first example where the string is located in the file is actually exactly where I would (eventually) predict it to be. When the leak occurs, it occurs between two 512-byte blocks of data. Since I'm not good enough at hexadecimal math, the hexadecimal address 0x4A23A000 is 1243848704 in decimal, and if I were to divide that by 512, I find that the leak occurs right before the 2429392th block.

Given this, I can also assume the second example is probably from the same file, because if I take the location of the string, subtract the length of the string found before, this string also then aligns with where the 2429408th block is expected. I did have my program first check the area directly preceding the header, since that where it seems most leaks occur, but if there's still an offset to the header, it then looks in the file. I think what's happening in append.c is the function tar_append_buffer actually writing out blocks of data at a time, and the strings for whatever reason get leaked between these blocks of data, although I'm not sure since I couldn't find the write function itself (it's hidden behind a macro or two and then a pointer...).

If at all possible, I want to avoid looking through the whole file because that runs the rare risk of removing a string that's supposed to be in the file and it slows down runtime dramatically.

And, yeah, I agree with abandoning PS3/4. Not only would it make a mess of libtar, but I think it would also make a mess of the recovery process. That would another step where something could possibly go wrong.

[megapro17]

I getting this error, when trying to recovery my data partition. It's happens on win002 file. How I can rescue my data? Should I use old version of twrp?

[5andr0]

I had the same problem on 3.0.3. But my tar files have no leaked strings inside! The problem was, that i didn't have enough space left on my data partition so i got the same error with this hint at the /tmp/recovery.log file: tar_extract_file(): failed to extract //data/app/ Would be nice to have a size check implemented or a more detailed error output if there's not enough space.

If you guys have tar problems, try to do do a cli data backup via adb shell without the -O option (compressed):

adb shell twrp backup D
adb shell twrp restore /external_sd/bak/ D

[jeffsf]

This is big problem, as often by the time you find out that you've got corrupted tar files, the data is already gone. Trying to make a "valid" backup of the data that has either changed since the backup was made, or been erased completely, is futile.

Note: As it turns out, this was not a corrupt tar file, as described above

• Nexus 5x
• twrp-3.0.2-2-bullhead.img (create)
• twrp-3.1.1-0-bullhead.img (restore)

Have to modify https://github.com/venerjoel99/TarProject a bit, as it needs at least #include <strings.h> to compile moderately cleanly under `nix. There is another warning around the format statement, but...

Regrettably, even after adding #include <string.h> and
cc *.c -o TarCleaner and appearing to run, the same 1024-byte file is created for every input file.

Trying https://github.com/BuildingAtom/CleanTwrpTar with cc -std=c99 CleanTwrpTar.c -o CleanTwrpTar now, and the command-line input of the input and output files means that it can be more easily scripted. Unfortunately, it appeared to produce a zero-byte output file.

While that was running, I tried egrep 'storing|Closing' data.ext4.win00? which returned no results. Which is rather concerning...

[jeffsf]

Looks like it is a different problem for me:

[...]
  ==> extracting: //data/ssh/ (mode 40700, directory)
  *** using existing directory
  ==> extracting: //data/ssh/ssh_host_dsa_key (file size 668 bytes)
  ==> extracting: //data/ssh/ssh_host_dsa_key.pub (file size 604 bytes)
  ==> extracting: //data/ssh/ssh_host_rsa_key (file size 1679 bytes)
  ==> extracting: //data/ssh/ssh_host_rsa_key.pub (file size 396 bytes)
  ==> extracting: //data/ssh/empty/ (mode 40000, directory)
tar_extract_file(): failed to extract //data/ssh/empty/ !!!

/data/ssh # ls -l
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
d---------    2 root     root          4096 Jan 28  2017 empty
-rw-------    1 root     root           668 Jan 28  2017 ssh_host_dsa_key
-rw-r--r--    1 root     root           604 Jan 28  2017 ssh_host_dsa_key.pub
-rw-------    1 root     root          1679 Jan 28  2017 ssh_host_rsa_key
-rw-r--r--    1 root     root           396 Jan 28  2017 ssh_host_rsa_key.pub

/data/ssh # rmdir /data/ssh/empty
rmdir: '/data/ssh/empty': Operation not permitted
/data/ssh # chmod 700 empty
chmod: empty/: Operation not permitted

Workaround was to manually extract the files

# cd /
# tar -xf path/to/data.ext4.win000 --exclude=/data/ssh/empty
# tar -xf path/to/data.ext4.win001 --exclude=/data/ssh/empty
# tar -xf path/to/data.ext4.win002 --exclude=/data/ssh/empty

and deal with /var/ssh/empty another day

[BuildingAtom]

@megapro17 Try compiling/running the two programs mentioned in this thread and using it on the win002 file. It's possible you're also having the same leaked strings issue.

@jeffsf I can only think that either the header for that directory was corrupted, or that for whatever reason you did not have permissions to actually extract that specific directory. Also, could you maybe open issues and add information regarding the problems you mentioned with the two programs? My friend and I are busy with moving into college right now, so we might not get to the issues right away, but if there are problems, we do want to fix them.

Also, the CleanTwrpTar program should be compiled with -std=c11 instead of c99. I wrote the program following C11 standards, so I'm not sure how it works under the C99 standard, but it probably doesn't.

[sithsupersu]

Im h I'm having the same problem with my Samsung. I have a Samsung J-3 SM j327p. Thor it comes back online but in a boot loop that's due because the bootloader is locked. I'm a noob at coding. Hope this might help out. When I restore all the partitions it it restores the system but in a boot loop.

[panpanika]

Hi, same here. twrp-3.1.1-0-santoni.img extractTarFork() process ended with ERROR: 255 tried win-prebuild https://github.com/venerjoel99/TarProject after quite while crunching produced 1kB files with NULs in them. Im half way re-installing so no point fixing backups for me, and I think Data backup is not good thing to share across internet for fix research, therefore just this report. Hope this helps somehow.

[aswery]

Hi Dude.. Just sharing ..

Device : Kenzo OS : Nitrogen 8.0 (beta) TWRP : 3.1.1 Official

The problem persist when i did restoring my back up :

createTarFork() process ended with ERROR=255

So.. It seems the problem happened when i make backup (even no error found) exactly in firmware partition backup.

I ve founded it by make 9 backup partitions (system, data, boot, recovery, cache, modem, firmware, BL and Efs) and do restoring one by one, and then the problem persist when I restored firmware partition

So I make this step when doing backup :

1. Open mount option and unchecked firmware partition.
2. Then I make full backup (9 partition)
3. The result is I got no error when restore it, and everything just fine now.

I don't even know the explanation, is there anyone can help explain it?, and is there any hidden problem with this way?

Seriously I Don't understand why but my backup and restoring running fine anyway now.. LOL

Just sharing my experiences, hope can help somebody here..

[mma8x]

Just a user here, but I'm trying to do a restore from one identical device to another. I was able to do it from device a-->b a couple of months ago, but now can't go from b-->a. A was running 3.0.x, and b 3.1.x. Tried making/restoring multiple backups without success. Weird thing is that if I try to restore the same backup on device b, it works.

UPDATE: Realized/remembered that the files in the data section are untouched when the partitions are wiped. In my case, I think that there wasn't enough room on the phone to extract the backup. Wiping the data partition completely (strangely this doesn't happen with a factory reset apparently) solved the issue.

[mperkel]

For what it's worth I ran into a similar situation where the rom I was restoring had a broken busybox inside it. That busybox wouldn't run tar. So the system directory restored using the tar in twrp, but after that it switched to the /system/bin directory (I think) and that ran the broken one. I also wonder if they should test and put a better tar into the toybox app to make sure tar actually works.

[mperkel]

In my case, and this worked, I copied the TWRP backup to a linux computer. I then untarred everything for my data directory and the used tar to make a huge tar file. I then pushed that to the external sd drive and then used the tar that came with TWRP to unpack it. And it worked.

Since the tar with Linux worked it makes me think that the tar used by TWRP is defective.

[venerjoel99]

@jeffsf @panpanika It seems that files with *.img extensions do not work with the programs. My best guess is that those backup files do not use the ustar format, so the programs do not have any file headers to parse. Without any file headers to parse, they would simply iterate through the backup file without analyzing or copying any of its content.

[bigbiff]

img files are a bit by bit copy of the raw filesystem and can be restored with dd if necessary.

[illumii]

first you have to restore everthing except data then as dexbyte said go to mount and unmount data then you have to select storage in restore and select microsdcard or internal storage youre choice then restore only data

[524c]

This error has been a long time, for me it no longer occurs in the latest version of TWRP.

[wseverin]

I was having this problem last night and today. Spent probably 8 hours trying to fix it. Finally I discovered that the most recent official TWRP available for my phone (a LeEco zl1), version 3.1.1, is not really the latest version. I found an unofficial version 3.2.1 for my phone (thanks codeworkx!!) and it fixed the problem.

[agudoe2]

If you still encounter the ERROR: 255 issue, try to prepare more space on internal storage. It works on me.

[maxammann]

Having the same problem on my oneplus 5. Decided to wipe my device since I couldn't even unpack the backup with tar.

[err53]

Same problem here on Oneplus 5T, had to reformat instead 😞

[half-duplex]

I had this problem on my moto x4 running 8.1.0. In recovery.log was something like tar_extract_file(): failed to extract //data/misc/bluedroid !!! and after messing with it a bit tar_extract_file(): failed to extract //data/system_de/0/accounts_de.db !!!. The solution for me was to do a factory reset, then boot to android, go all the way through the OOBE setup, then boot back to recovery and do the restore.

[yipinghuang1991]

I met the same error message with a totally different cause. I use an xposed ad blocking app called "大聖淨化", which has an ability to change any empty user-specified folder (that contains ad files) to a file of the same name (so that there is no ad to be read). But that file survives data wipe, which, upon restoring data partition, leads to the error "extractTarFork() process ended with ERROR: 255". It turns out reformatting the data partition fixed my problem.

[tuxayo]

Same issue, Moto G3, version 3.2.3-0 Happens after ~570 MB over 2271MB to restore. And reformatting didn't help.

https://github.com/TeamWin/Team-Win-Recovery-Project/issues/964#issuecomment-360971264

first you have to restore everthing except data then as dexbyte said go to mount and unmount data then you have to select storage in restore and select microsdcard or internal storage youre choice then restore only data

It didn't work either.

Here are the logs.

dmesg.log recovery.log

  ==> extracting: //data/misc/profiles/cur/0/com.android.externalstorage/ (mode 40700, directory)
  ==> extracting: //data/misc/profiles/cur/0/com.android.externalstorage/primary.prof (file size 0 bytes)
  ==> extracting: //data/misc/profiles/cur/0/com.android.htmlviewer/ (mode 40700, directory)
  ==> extracting: //data/misc/profiles/cur/0/com.android.htmlviewer/primary.prof (file size 0 bytes)
  ==> extracting: //data/misc/profiles/cur/0/com.android.mms.service/ (mode 40700, directory)
  ==> extracting: //data/misc/profiles/cur/0/com.android.mms.service/primary.prof (file size 0 bytes)
  ==> extracting: //data/misc/profiles/cur/0/com.android.mms.service/primary.prof (link to //data/misc/profiles/cur/0/com.android.mms.service/primary.prof)
tar_extract_hardlink(): failed restore of hardlink '//data/misc/profiles/cur/0/com.android.mms.service/primary.prof' but returning as if nothing bad happened
tar_extract_file(): failed to set permissions on //data/misc/profiles/cur/0/com.android.mms.service/primary.prof !!!
I:Unable to extract tar archive '/external_sd/TWRP/BACKUPS/ZY222X5PRM/2018-09-05--04-21-46_lineage_osprey-userdebug_712_NJH47F_2018082/data.f2fs.win000'
Error during restore process.
I:Error extracting '/external_sd/TWRP/BACKUPS/ZY222X5PRM/2018-09-05--04-21-46_lineage_osprey-userdebug_712_NJH47F_2018082/data.f2fs.win000' in thread ID 0
I:Error extracting split archive.
Error during restore process.
extractTarFork() process ended with ERROR: 255

Is there something else to try?

[maxammann]

Recently tried it again without luck on latest recovery on oneplus 5

[tuxayo]

In my case, my backup is corrupted. The sha256 matches but:

• tar reports errors when extracting "Malformed extended header: missing equal sign" and ends up failing
• even grepping the tar file for the name of my target file or it's content didn't work. See this amazing post about this last hope solution: https://stosb.com/blog/recovering-data-from-a-corrupt-tar-archive/

So the theory that I have is: Corrupted sdcard which didn't write everything. So the calculated sha256 sum matches to what is reread from the sdcard. Even if what is read isn't what was written (well at least send to be written).

Going further: one enhancement when creating the backup could be to direct the data stream from tar to backup file of course, but also to sha256sum. So we would have a checksum of what's going be to written on the SD card. And then we keep the last step of checksum calculation (the current one, which reads the backup file). And we can compare both. And report such cases of corrupted SD card at backup creation time. With the only performance cost of having a sha256 computation in parallel of the file writing. Which should have no impact, except when compressing the backup where the CPU might often be the bottleneck. But it should not be much considering the low time of generating a checksum for the whole backup afterwards. So a dozen MiB/s should be steal much CPU from the compression. Is this ↑ "going futher" part worth creating an issue?

[Drigtime]

I have the same error, what is the point of using TWRP to make a backup if in the end you will not even be able to restore 😞

[maxammann]

@Drigtime Yes, this is a very big bummer. I noticed this a few month ago. Since then I'm prepared when upgrading linageos and backup everything before that with TitaniumBackup. Safed my ass a few days ago.

[bscout9956]

A friend is having issues with this on his OnePlus 5. I feel like I should comment just for the sake of visibility. Just to add up to the number of people with that particular issue.

[ursul0]

Hi Dude.. Just sharing ..

Device : Kenzo OS : Nitrogen 8.0 (beta) TWRP : 3.1.1 Official

The problem persist when i did restoring my back up :

createTarFork() process ended with ERROR=255

So.. It seems the problem happened when i make backup (even no error found) exactly in firmware partition backup.

I ve founded it by make 9 backup partitions (system, data, boot, recovery, cache, modem, firmware, BL and Efs) and do restoring one by one, and then the problem persist when I restored firmware partition

So I make this step when doing backup :

1. Open mount option and unchecked firmware partition.
2. Then I make full backup (9 partition)
3. The result is I got no error when restore it, and everything just fine now.

I don't even know the explanation, is there anyone can help explain it?, and is there any hidden problem with this way?

Seriously I Don't understand why but my backup and restoring running fine anyway now.. LOL

Just sharing my experiences, hope can help somebody here..

yes very interesting indeed... I'm getting error 255 on TWRP restore of firmware partition on redmi note4x. no matter what I do my firmware partition just won't get captured properly. all seems fine during backup. Opting to skip thefirmware restore and then flashing stand alone fw from MIUI stock rom fixes the annoyance. But still....

P.S. also the BuildingAtom's tool indeed finds some apparently leaked strings in the firmware file, but the "fixed" result still gives the same error

[liudonghua123]

I have the same problem while using TWRP_3.1.0-0_multirom_hammerhead_20170314-03.img (https://androidfilehost.com/?w=files&flid=102780) to recovery android P (https://www.firstever.eu/download/FirstEver-Android-9.0-20181004.rar) on my nexus 5.

[oregszun]

Hello Guys,

same issue on an SM-T805 and TWRP 3.2.3-1! Only DATA partition affected.

$ tar xf data.ext4.win002 -C ./data tar: Removing leading `/' from member names tar: Malformed extended header: missing equal sign

[oregszun]

I just created a manual tarball backup in TWRP console and there is no issue with the created file.

[maxammann]

@oregszun Did you try to restore from a manual tar backup? Would be cool to hear your experience.

[jj999]

I've had the same error in TWRP 3.2.3 when restoring "/data" partition. I've got Error 255 when restore reached about 56%. Then I discovered I've had two TWRP backups in internal /data/media partition by mistake and I moved them to external partition (via TWRP). Then I repeated restore of /data and it worked fine :-) So please check if your /data/media does not contain uncessary stuff and repeat. I hope it helps somebody.