[Bug] The file path name is too long to report an error

[rankaiyx]

Description The file path name is too long to report an Error Error report: "... tar ... >100bytes"

Expected behavior It works properly when the file pathname is longer than 100bytes

Screenshots

System Information(please complete the following information):

• Device: nubiax
• Android Version: 9
• ROM: Android
• App's Version: 8.3.1

[hg42]

not sure if it is about the length of the file path. Though the path is 127 bytes long, which looks like it could be clipped.

Did you check the path, is it clipped?

Usually, I would say it's about the difference between the size tar saw when collecting files to archive and the actual size when tar streamed that file. It would mean it thought it would be 100 bytes, but then when reading and packing it into the archive, it was longer.

It's a library file, which usually doesn't change. However, the file path looks like wechat crashed at the time of the backup ("backtrace") and was saving files related to the crash or similar.

Apart from that, it is an error coming from tar which is part of toybox. We would have to request a fix in toybox (or find one ourselves, which we already did for another bug), but unfortunately fixes don't propagate easily down to Android sources (e.g. our fix still isn't in current Androids as far as I know, I've given up looking for it).

[rankaiyx]

not sure if it is about the length of the file path. Though the path is 127 bytes long, which looks like it could be clipped.

Did you check the path, is it clipped?

Usually, I would say it's about the difference between the size tar saw when collecting files to archive and the actual size when tar streamed that file. It would mean it thought it would be 100 bytes, but then when reading and packing it into the archive, it was longer.

It's a library file, which usually doesn't change. However, the file path looks like wechat crashed at the time of the backup ("backtrace") and was saving files related to the crash or similar.

Apart from that, it is an error coming from tar which is part of toybox. We would have to request a fix in toybox (or find one ourselves, which we already did for another bug), but unfortunately fixes don't propagate easily down to Android sources (e.g. our fix still isn't in current Androids as far as I know, I've given up looking for it).

The problem is not caused by the length of the file pathname. I manually created files with very long folder names and file names in some app's data/data directory. And it can be successfully backed up.

[rankaiyx]

(or find one ourselves, which we already did for another bug)

If you can provide the installation package, I can test it to see if this problem can be solved by the way.

[hg42]

ok, thanks for testing the path length.

so it is this:

It would mean it thought it would be 100 bytes, but then when reading and packing it into the archive, it was longer

this is a well known problem, when running backups in a running system. We try to pause everything related to the app and it's data, but this will never be perfect.

From my experience it works best, when going offline before the backup. Most apps change their data online. Naturally, there are also apps that collect data without internet. E.g. a gps tracking app, or physical measurements, or similar.

[rankaiyx]

Thank you for your reply, but unfortunately, I froze the app, and the phone turned on flight mode and reboot the phone. The problem still exists.

[biezou999]

So how to solve this problem I also encountered a similar problem The new version of NEO above 8.0 is this problem You can use the 7.0 version There is no problem but the backup of 7.0 is very slow....

[hg42]

not sure, but I guess, 7.0 does not use tar. You could disable tar, the old code still exists, though this wasn't tested any more since introducing tar. You just stepped up to the tester level.

[hg42]

the cause of the error is still a bit mysterious.

Let's elaborate...

The tar source contains this structure:

// The on-disk 512 byte record structure.
struct tar_hdr {
  char name[100], mode[8], uid[8], gid[8], size[12], mtime[12], chksum[8],
       type, link[100], magic[8], uname[32], gname[32], major[8], minor[8],
       prefix[155], padd[12];
};

so the limit seems to be in the tar file format. I guess there are more recent versions of the format, but then toybox tar does not support them.

It looks like the path is split into prefix and name, so they are less limited.

Obviously the message originates from xstrncpy or xstrncat (string routines with size checking). The path uses xmprintf and this doesn't produce this " > 100 bytes" error message (at least not in the toybox source).

tar.c contains 5 of them:

toys/posix/tar.c:741:    TT.hdr.uname = xstrndup(TT.owner ? : tar.uname, sizeof(tar.uname));
toys/posix/tar.c:742:    TT.hdr.gname = xstrndup(TT.group ? : tar.gname, sizeof(tar.gname));
toys/posix/tar.c:757:      TT.hdr.link_target = xstrndup(tar.link, sizeof(tar.link));
toys/posix/tar.c:917:      TT.owner = xstrndup(TT.owner, s++-TT.owner);
toys/posix/tar.c:924:      TT.group = xstrndup(TT.group, s++-TT.group);

So, it seems the error is caused by a long link?

Is the mentioned file a link?

this also fits to the observation that long file names and directory paths work. I think they are probably limited to 100 bytes for the name and 155 bytes for the directory path. But links are limited to 100 bytes for the whole path it is linking to.