On 1/12/2021 12:15 PM, Corinna Vinschen wrote:
On Jan 12 11:55, Ken Brown via Cygwin wrote:
On 1/11/2021 6:50 PM, Ken Brown via Cygwin wrote:
On 1/11/2021 2:57 PM, Morgan King via Cygwin wrote:
Hello,
I am experiencing the same issue with tar and I am able to reproduce
it following the steps at:
https://lists.gnu.org/archive/html/bug-tar/2011-08/msg00006.html
This issue only appears to occur when using 32-bit Cygwin, I am
unable to reproduce it using 64-bit Cygwin.
I can confirm this. Running the tar command under gdb shows a problem
at gnu/fchmodat.c:94:
94 if (S_ISLNK (st.st_mode))
Here st is a stat structure for directory/1, so S_ISLNK() should be
true. It is indeed true on 64-bit Cygwin but not on 32-bit Cygwin.
Someone needs to look more closely and find out why this happened. I'll
try to do it tomorrow if no one beats me to it.
This appears to be a bug in fstat in 32-bit Cygwin. Here's what I'm seeing
in gdb, using an unoptimized build of cygwin1.dll. There is a call to
fstatat in the tar source file gnu/fchmodat.c:87. This ultimately leads to
a call to fstat, whose definition in syscalls.cc is the following in the
32-bit case:
No, wait. struct stat == struct _stat64 since Cygwin 1.5.0!
With Cygwin 1.5.0, the old entry point fstat was only retained to serve
old 32 bit applications buil.t under Cygwin 1.3.x or earlier.
Consequentially, newer 32 bit apps, built with Cygwin 1.5.0 or later,
are redirected to fstat64, see NEW_FUNCTIONS in Makefile.in.
If tar is actually calling fstat, something fishy is going on.
It's not tar that's calling fstat, it's Cygwin's fstatat at syscalls.cc:4855.
This appears to be a bug that I introduced in commit 84252946. I'll fix it.
Thanks for setting me straight.
Ken
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
