On 2023-05-26 00:27, Brian Inglis via Cygwin wrote:
On 2023-05-25 22:52, Denis Excoffier wrote:
On 2023-05-25 09:52, Brian Inglis via Cygwin wrote:
On 2023-05-24 12:18, Denis Excoffier via Cygwin wrote:
I have an error (about symlinks it seems) that i have never met in years:
Cannot change mode.
Apart from this message (and return code != 0), the ?tar extract? is ok.
% uname -a
CYGWIN_NT-10.0-17763 {edited} 3.5.0-0.295.g3bee68248fc8.x86_64 2023-05-01
17:58 UTC x86_64 Cygwin
% cd /tmp; rm -rf mytest mytest.tar
% mkdir mytest
% ln -s b mytest/a
% /bin/tar cf /tmp/mytest.tar mytest
% /bin/tar tvf /tmp/mytest.tar
drwxr-xr-x {edited}/{edited} 0 2023-05-24 13:12 mytest/
lrwxrwxrwx {edited}/{edited} 0 2023-05-24 13:12 mytest/a -> b
% rm -rf mytest
% /bin/tar xf /tmp/mytest.tar
/bin/tar: mytest/a: Cannot change mode to rwxr-xr-x: Not a directory
/bin/tar: Exiting with failure status due to previous errors
% echo $status
2
%
/tmp is under ntfs filesystem, all packages are up to date (e.g. /bin/tar
--version is 1.34).
I recently got this during a package update build, when it decided to tar a
build directory, which contained only symlinks to files in the src directory,
which the tar did not include, which would have created many dangling symlinks.
I fixed the issue by adding -h, --dereference to give chf and tar real files.
Sorry I failed to make my meaning clear.
The issue may be that tar can not apply file permissions to a symlink target
which does not (yet) exist in the filesystem.
I don’t catch this. A symlink, dangling or not, is a normal file. In any case,
the problem is the
same if the symlink target is a member in the archive. See for example
% mkdir -p /tmp/mytest2; cd /tmp/mytest2
% tar xf cygwin-devel-3.5.0-0.295.g3bee68248fc8.tar.xz
/bin/tar: usr/lib/libg.a: Cannot change mode to rwxr-xr-x: Not a directory
/bin/tar: Exiting with failure status due to previous errors
What is .../libg.a in the tar file; is it a symlink link or target?
I add that my symlinks are default ones, i.e. JUNCTIONS.
What is your CYGWIN=winsymlinks:... setting: native or nativestrict?
I have no idea how tar is likely to view or handle a Windows junction,
especially if it has not yet been created!
The *default* symlinks are *sys*:
"CYGWIN=winsymlinks:{lnk,native,nativestrict,sys}
If set to just winsymlinks or winsymlinks:lnk, Cygwin creates symlinks as
Windows shortcuts with a special header and the R/O attribute set.
If set to winsymlinks:native or winsymlinks:nativestrict, Cygwin creates
symlinks as native Windows symlinks on filesystems and OS versions supporting them.
The difference between winsymlinks:native and winsymlinks:nativestrict is this:
If the filesystem supports native symlinks and Cygwin fails to create a native
symlink for some reason, it will fall back to creating Cygwin default symlinks
with winsymlinks:native, while with winsymlinks:nativestrict the symlink(2)
system call will immediately fail.
If set to winsymlinks:sys, Cygwin creates symlinks as plain files with the
system attribute, containing a magic cookie followed by the path to which the
link points.
Note that this setting has no effect where Cygwin knows that the filesystem only
supports a creating symlinks in a specific way.
For more information on symbolic links, see the section called “Symbolic links”.
Problem seems to be Cygwin 3.5.0 - reinstall Cygwin stable 3.4.6 and the problem
goes away!
See other thread I just started.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry
--
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
