Unbreak tar on older kernels

[NiLuJe]

Re koreader/koreader#7140

("Regression" thanks to a gnulib update in tar 1.33).

---

This change is 

[NiLuJe]

00:54:41.909573 [2abcc118] lchown32("/proc/self/fd/4/./l10n", 0, 0) = 0
00:54:41.909755 [2abcad18] openat(4</mnt/usbms>, "./l10n", O_RDONLY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 3</mnt/usbms/l10n>
00:54:41.909946 [2abca4f8] fstatat64(3</mnt/usbms/l10n>, "", 0x7e972ba8, AT_EMPTY_PATH) = -1 EINVAL (Invalid argument)

vs.

00:55:32.575915 [2abb6118] lchown32("/proc/self/fd/4/./l10n", 0, 0) = 0
00:55:32.576085 [2abb44f8] fstatat64(4</mnt/usbms>, "./l10n", {st_dev=makedev(0, 0x10), st_ino=11465, st_mode=S_IFDIR|0700, st_nlink=19, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=380, st_atime=1610754932 /* 2021-01-16T00:55:32.190982067+0100 */, st_atime_nsec=190982067, st_mtime=1607907000 /* 2020-12-14T01:50:00+0100 */, st_mtime_nsec=0, st_ctime=1610754932 /* 2021-01-16T00:55:32.571000281+0100 */, st_ctime_nsec=571000281}, AT_SYMLINK_NOFOLLOW) = 0
00:55:32.576533 [2abb488c] fchmodat(4</mnt/usbms>, "./l10n", 0755) = 0
00:55:32.576694 [2abb44f8] fstatat64(4</mnt/usbms>, ".", {st_dev=makedev(0, 0x10), st_ino=10363, st_mode=S_IFDIR|0755, st_nlink=5, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=120, st_atime=1610752808 /* 2021-01-16T00:20:08.541000281+0100 */, st_atime_nsec=541000281, st_mtime=1610754932 /* 2021-01-16T00:55:32.320997726+0100 */, st_mtime_nsec=320997726, st_ctime=1610754932 /* 2021-01-16T00:55:32.320997726+0100 */, st_ctime_nsec=320997726}, 0) = 0
00:55:32.577140 [2abba954] utimensat(4</mnt/usbms>, ".", [UTIME_OMIT, {tv_sec=1607907000, tv_nsec=0} /* 2020-12-14T01:50:00+0100 */], 0) = 0

[NiLuJe]

stat(2):

AT_EMPTY_PATH (since Linux 2.6.39)

uname -a
Linux kobo 2.6.35.3-850-gbc67621+ #3032 PREEMPT Mon Jan 9 13:37:40 CST 2017 armv7l GNU/Linux

;o)

[NiLuJe]

(Because the AT_EMPTY_PATH define is provided by the glibc, not the kernel headers).

[lancethepants]

Hey! Just found this fix because I've had issues on older kernels as well. Was just going to ask if there's been any attempt to upstream this? tar-1.34 still has same issue as well.

[NiLuJe]

No, because it's highly crappy and ugly, and is definitely the kind of thing that should stay downstream ;).

[NiLuJe]

And I actually just re-read the patch, and it's not a patch at all, it's just a gross hack to disable the offending feature ;p.

(I do have slightly less fugly patches for that sort of thing that do a runtime kernel level check, that's what I was thinking about in my previous answer ;)).