Updated: coreutils 9.1
Brian Inglis wrote: >> Setup still shows 9.1 as test, but it should not be installed by anyone. >> Setup now also shows 9.0 in test, and it can and should be installed by >> anyone who experienced issues with 9.1. Jim Reisert wrote: > 9.0 (test) is working for me now, whereas 9.1 did not work. > Thanks for the fixes! .. can and should be installed .. Done. 9.0 (test) is working for me now, whereas 9.1 did not work. (I had earlier reported a glitch.) Thank you! -- 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
Re: Updated: coreutils 9.1
On Tue, Jul 19, 2022 at 10:46 AM Brian Inglis wrote: > Setup still shows 9.1 as test, but it should not be installed by anyone. > Setup now also shows 9.0 in test, and it can and should be installed by > anyone who experienced issues with 9.1. 9.0 (test) is working for me now, whereas 9.1 did not work. Thanks for the fixes! -- Jim Reisert AD1C, , https://ad1c.us -- 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
Re: Updated: coreutils 9.1
Setup still shows 9.1 as test, but it should not be installed by anyone. Setup now also shows 9.0 in test, and it can and should be installed by anyone who experienced issues with 9.1. I ran it for a couple of weeks in my installs with no apparent issues before releasing it for testing. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] On 2022-07-19 10:22, Jim Reisert AD1C wrote: On Mon, Jun 6, 2022 at 11:34 AM Jim Reisert AD1C wrote: On Tue, May 24, 2022 at 10:33 AM, Jim Reisert AD1C wrote: Brian, the latest version (9.1-1 I think) from July 2022 still has the problem documented below. I reverted to the non-test version and it's working as it should. [8PZCBK3:~/DXspots] $ make -n update_last_month make update QSNDATE=2206 LISDATE=Jun-2022 YEAR=2022 make[1]: Entering directory '/cygdrive/c/users/jr920141/Home/DXspots' echo "" if [ -a 2022/QSN2206.EXC ]; then cp -pvf 2022/QSN2206.EXC here; fi if [ -a 2022/QSN2206.TXT ]; then cp -pvf 2022/QSN2206.TXT here; fi if [ -a 2022/ignore.csv ]; then cp -pvf 2022/ignore.csv here; fi [8PZCBK3:~/DXspots] $ make update_last_month make[1]: Entering directory '/cygdrive/c/users/jr920141/Home/DXspots' '2022/QSN2206.TXT' -> 'here/QSN2206.TXT' cp: cannot create regular file 'here/QSN2206.TXT': File exists make[1]: *** [Makefile:262: here] Error 1 The following package has been in test for two weeks with no reported or obvious issues and has now been upgraded to current stable in the Cygwin distribution: * coreutils 9.1 I really try NOT to contact the maintainers directly. But in this case, I did report a bug to the Cygwin list, and received no feedback. I copied my posting below: The following test package has been uploaded to the Cygwin distribution: * coreutils 9.1 I am having a problem with "cp" that is not present in the previous (non-test) version. I'm running the latest Cygwin on Windows 10: CYGWIN_NT-10.0-19044 8PZCBK3 3.3.5-341.x86_64 2022-05-13 12:27 UTC x86_64 Cygwin The "cp" commands are in a Makefile. These are all text (not binary) files. "here" is a directory. if [ -a 2022/QSN2205.EXC ]; then cp -pvf 2022/QSN2205.EXC here; fi if [ -a 2022/QSN2205.TXT ]; then cp -pvf 2022/QSN2205.TXT here; fi if [ -a 2022/ignore.csv ]; then cp -pvf 2022/ignore.csv here; fi These are the target files that are being copied *to*: -rw-rw+ 1 jr920141 Domain Users11022 May 23 08:01 here/ignore.csv -rw-rw+ 1 jr920141 Domain Users 303543 May 23 10:25 here/QSN2205.EXC -rw-rw+ 1 jr920141 Domain Users 14395440 May 23 08:00 here/QSN2205.TXT These are the source files that are being copied *from*: -rw-rw+ 1 jr920141 Domain Users11303 May 24 08:20 ignore.csv -rw-rw+ 1 jr920141 Domain Users20944 May 24 10:17 QSN2205.EXC -rw-rw+ 1 jr920141 Domain Users 14941120 May 24 08:19 QSN2205.TXT It just so happens that the files are (now) the same. I had already done the copy and no longer have the old files that were in the "here" directory. But it doesn't matter whether the files are the same or different. The problem still occurs. This is the result: [8PZCBK3:~/DXspots] $ make here '2022/QSN2205.EXC' -> 'here/QSN2205.EXC' '2022/QSN2205.TXT' -> 'here/QSN2205.TXT' cp: cannot create regular file 'here/QSN2205.TXT': File exists It makes no sense to me that the .EXC file was copied overtop of the existing file, file but the .TXT file was not. The TXT file has DOS line endings. The EXC file does not. I don't see why that would/should make a difference. cygcheck.out is attached. -- 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
Re: Updated: coreutils 9.1 cp problem
Hi Fergus, Verified and confirmed. Please reinstall 8.32 until I can get this reverted in setup. Have requested 9.1 be reverted to test and 8.32 reverted to current stable. On 2022-06-06 21:21, Fergus Daly wrote: Since updating from coreutils 8.32 I’m getting a weird glitch from cp. If /location1/dir1/ contains additional material to /location2/dir1/ (as might frequently be the case when maintaining a backup) then the command $ cp -vrn /location1/dir1 /location2 should copy the additional material across. (I do this regularly, working in two locations on two machines with a stick to manage the transactions.) Since updating coreutils, this command yields an error message as follows: $ cp -vrn /location1/dir1 /location2 /bin/cp: cannot create directory '/location2/dir1': File exists I haven’t tried any other variations on cp or explored any other commands (e.g. ls) that have altered with the update. This occurs in both 32-bit and 64-bit Cygwin. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] -- 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
Re: Updated: coreutils 9.1
Since updating from coreutils 8.32 I’m getting a weird glitch from cp. If /location1/dir1/ contains additional material to /location2/dir1/ (as might frequently be the case when maintaining a backup) then the command $ cp -vrn /location1/dir1 /location2 should copy the additional material across. (I do this regularly, working in two locations on two machines with a stick to manage the transactions.) Since updating coreutils, this command yields an error message as follows: $ cp -vrn /location1/dir1 /location2 /bin/cp: cannot create directory '/location2/dir1': File exists I haven’t tried any other variations on cp or explored any other commands (e.g. ls) that have altered with the update. This occurs in both 32-bit and 64-bit Cygwin. Fergus -- 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
[ANNOUNCEMENT] Updated: coreutils 9.1
The following package has been in test for two weeks with no reported or obvious issues and has now been upgraded to current stable in the Cygwin distribution: * coreutils 9.1 GNU core utilities (includes fileutils, shellutils and textutils) Common core utilities include: [ arch b2sum base32 base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold gkill groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes For more information, see the project home pages: https://www.gnu.org/software/coreutils https://savannah.gnu.org/projects/coreutils In case of doubts about changes, it may be useful to check the FAQ or Gotchas: https://www.gnu.org/software/coreutils/faq/coreutils-faq.html https://www.pixelbeat.org/docs/coreutils-gotchas.html For the many changes since the previous Cygwin release, see below or read /usr/share/doc/coreutils/NEWS after installation; for complete details see: https://github.com/coreutils/coreutils/blob/v9.1/NEWS https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=log;h=refs/tags/v9.1 /usr/share/doc/coreutils/ChangeLog Noteworthy changes in release 9.1 (2022-04-15) Bug fixes * chmod -R no longer exits with error status when encountering symlinks. All files would be processed correctly, but the exit status was incorrect. [bug introduced in coreutils-9.0] * If 'cp -Z A B' checks B's status and some other process then removes B, cp no longer creates B with a too-generous SELinux security context before adjusting it to the correct value. [bug introduced in coreutils-8.17] * 'cp --preserve=ownership A B' no longer ignores the umask when creating B. Also, 'cp --preserve-xattr A B' is less likely to temporarily chmod u+w B. [bug introduced in coreutils-6.7] * On macOS, 'cp A B' no longer miscopies when A is in an APFS file system and B is in some other file system. [bug introduced in coreutils-9.0] * On macOS, fmt no longer corrupts multi-byte characters by misdetecting their component bytes as spaces. [This bug was present in "the beginning".] * 'id xyz' now uses the name 'xyz' to determine groups, instead of xyz's uid. [bug introduced in coreutils-8.22] * 'ls -v' and 'sort -V' no longer mishandle corner cases like "a..a" vs "a.+" or lines containing NULs. Their behavior now matches the documentation for file names like ".m4" that consist entirely of an extension, and the documentation has been clarified for unusual cases. [bug introduced in coreutils-7.0] * On macOS, 'mv A B' no longer fails with "Operation not supported" when A and B are in the same tmpfs file system. [bug introduced in coreutils-9.0] * 'mv -T --backup=numbered A B/' no longer miscalculates the backup number for B when A is a directory, possibly inflooping. [bug introduced in coreutils-6.3] Changes in behavior * cat now uses the copy_file_range syscall if available, when doing simple copies between regular files. This may be more efficient, by avoiding user space copies, and possibly employing copy offloading or reflinking. * chown and chroot now warn about usages like "chown root.root f", which have the nonstandard and long-obsolete "." separator that causes problems on platforms where user names contain ".". Applications should use ":" instead of ".". * cksum no longer allows abbreviated algorithm names, so that forward compatibility and robustness is improved. * date +'%-N' now suppresses excess trailing digits, instead of always padding them with zeros to 9 digits. It uses clock_getres and clock_gettime to infer the clock resolution. * dd conv=fsync now synchronizes output even after a write error, and similarly for dd conv=fdatasync. * dd now counts bytes instead of blocks if a block count ends in "B". For example, 'dd count=100KiB' now copies 100 KiB of data, not 102,400 blocks of data. The flags count_bytes, skip_bytes and seek_bytes are therefore obsolescent and are no longer documented, though they still work. * ls no longer colors files with capabilities by default, as file-based capabilties are very rarely used, and lookup increases processing per file by about 30%. It's best to use getcap [-r] to identify files with capabilities. * ls no longer tries to automount files, reverting to the behavior before the statx() call was introduced in coreutils-8.32. * stat no longer tries to automount files by default, reverting to the behavior before the statx() call was introduced in coreutils-8.32. Only `
