GDAL Update

[Nejia Ben Nasr via Cygwin]

Hi,

I would like to know if you have set a date for updating the GDAL package 
following the correction for reading geotiff images.
GDAL doesn't read geotiff 
(cygwin.com)

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

GDAL doesn't read geotiff

[Nejia Ben Nasr via Cygwin]

Hi all,

I downloaded the last version of GDAL package.
gdalinfo on any tiff file give "Segmentation fault".

$ gdalinfo --version
GDAL 3.8.3, released 2024/01/04

$ gdalinfo test.tif --config CPL_DEBUG ON
GDAL: GDALOpen(test.tif, this=0xa000bbe70) succeeds as GTiff.
Driver: GTiff/GeoTIFF
Segmentation fault


CALL STACK:
cygtiff-6.dll!cygtiff-6!TIFFUnlinkDirectory (Unknown Source:0)
cygwin1.dll!bsearch(const void * key, const void * base, size_t nmemb, size_t 
size, int (*)(const void *, const void *) compar) 
(c:\cygwin64\usr\src\debug\cygwin-3.5.0-1\newlib\libc\search\bsearch.c:79)
cygtiff-6.dll!cygtiff-6!TIFFFindField (Unknown Source:0)
cygtiff-6.dll!cygtiff-6!TIFFVGetField (Unknown Source:0)
cygtiff-6.dll!cygtiff-6!TIFFGetField (Unknown Source:0)
cyggeotiff-5.dll!_GTIFGetField(tiff_t * tif, pinfo_t tag, int * count, void * 
val) (c:\cygwin64\usr\src\debug\libgeotiff-1.7.1-2\geo_tiffp.c:86)
cyggeotiff-5.dll!GTIFNewWithMethodsEx(void * tif, TIFFMethod * methods, 
GTErrorCallback error_callback, void * user_data) 
(c:\cygwin64\usr\src\debug\libgeotiff-1.7.1-2\geo_new.c:133)
cyggeotiff-5.dll!GTIFNewEx(void * tif, GTErrorCallback error_callback, void * 
user_data) (c:\cygwin64\usr\src\debug\libgeotiff-1.7.1-2\geo_new.c:84)
cyggdal-34.dll!GTiffDataset::GTIFNew(TIFF * hTIFF) 
(c:\cygwin64\usr\src\debug\gdal-3.8.3-1\frmts\gtiff\gtiffdataset.cpp:1613)
cyggdal-34.dll!GTiffDataset::LoadGeoreferencingAndPamIfNeeded(GTiffDataset * 
const this) 
(c:\cygwin64\usr\src\debug\gdal-3.8.3-1\frmts\gtiff\gtiffdataset_read.cpp:5833)
cyggdal-34.dll!GTiffRasterBand::GetMetadataItem(GTiffRasterBand * const this, 
const char * pszName, const char * pszDomain) 
(c:\cygwin64\usr\src\debug\gdal-3.8.3-1\frmts\gtiff\gtiffrasterband_read.cpp:1532)
cyggdal-34.dll!GDALRasterBand::GetStatistics(GDALRasterBand * const this, int 
bApproxOK, int bForce, double * pdfMin, double * pdfMax, double * pdfMean, 
double * pdfStdDev) 
(c:\cygwin64\usr\src\debug\gdal-3.8.3-1\gcore\gdalrasterband.cpp:4316)


I also tried to build from sources as folow:
$ cmake .. \
   -DCMAKE_BUILD_TYPE=Release \
   -DCMAKE_INSTALL_PREFIX=/cygdrive/d/gdal-release-3.8/install \
   -DGDAL_USE_INTERNAL_LIBS=ON \
   -DGDAL_USE_EXTERNAL_LIBS=OFF \
   -DGDAL_BUILD_OPTIONAL_DRIVERS=OFF \
   -DOGR_BUILD_OPTIONAL_DRIVERS=OFF

$ make

In file included from /usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/map:60,
 from /cygdrive/d/gdal-release-3.8/gcore/gdal_priv.h:7,
 from /cygdrive/d//gdal-release-3.8/apps/gdalinfo_lib.cpp:55:
/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/bits/stl_tree.h:350:1: error: 
expected unqualified-id before numeric constant
  350 | 1  _Rb_tree_const_iterator(const iterator& __it) _GLIBCXX_NOEXCEPT
  | ^
make[2]: *** [apps/CMakeFiles/appslib.dir/build.make:76: 
apps/CMakeFiles/appslib.dir/gdalinfo_lib.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:3038: apps/CMakeFiles/appslib.dir/all] Error 
2
make: *** [Makefile:146: all] Error 2

For more details about this issue I uploaded here a 
small Tiff file that you can check as well as cygcheck outputs and call stack.


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

[no subject]

[Ben Sim via Cygwin]

1 [main] wit 21172 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.

Sent from Mail for Windows


-- 
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: Cygwin64 does not show my desktop directories

[Voris, Ben via Cygwin]

> -Original Message-
> From: Takashi Yano 
> Sent: 19 July 2023 03:15
> To: cygwin@cygwin.com
> Cc: Orit Heimer 
> Subject: Re: Cygwin64 does not show my desktop directories
> 
> On Wed, 19 Jul 2023 11:52:31 +0300
> Orit Heimer wrote:
> > Hello to all,
> > I am new to Cygwin64 and encountered a problem.
> > I am using a Windows 10.
> > I try to get cygwin64 to show my desktop directories.
> > I use the following command to change to this directory:
> > *cd /cygdrive/c/Users/Default/Desktop*
> > But when I then use *ls* I get nothing.
> > I suspect this is a permission problem, but I failed to overcome it.
> 
> The directory you cd'ed is not correct.
> Use:
> /cygdrive/c/Users/$USER/Desktop
> 
> --
> Takashi Yano 

If you can "cd" to a directory and "ls" shows it empty, permissions
are unlikely to be the problem.

Though the original example used "C:", the Windows desktop need not
be on the C: drive. Assuming you're using bash, a more general command
is:

cd "${USERPROFILE}/Desktop"

- Quoted because doing that helps to remind me that its safer. 
- ${USERPROFILE} because it includes the Windows drive.
- "Desktop" instead of "desktop" because, though case-sensitivity is
  usually not enabled, the directory name is "Desktop".

Also, it is possible that the directory that Windows Explorer shows
as your desktop is something entirely different. For example, if you
use OneDrive to mirror your desktop, the directory that Windows
Explorer shows is "${OneDrive}/Desktop". And, at least on my system,
Here, the quotes are necessary.

I believe that OneDrive isn't the only thing that can change the
"real" location of what Windows Explorer shows:

The following command should always work but will emit
"bash: warning: command substitution: ignored null byte in input".
In case email makes a mess of the command, it is 128 characters.

ls -ld "$(cat 
"/proc/registry/HKEY_CURRENT_USER/SOFTWARE/Microsoft/Windows/CurrentVersion/Explorer/User
 Shell Folders/Desktop")"

If you don't like to see the warning and you want to have a variable
that holds the desktop directory name, this works. Again, to help in
case email makes a mess of it, the command is 202 characters.

IFS= read -r -d '' WINDOWS_DESKTOP < 
"/proc/registry/HKEY_CURRENT_USER/SOFTWARE/Microsoft/Windows/CurrentVersion/Explorer/User
 Shell Folders/Desktop" && WINDOWS_DESKTOP="$(cygpath "${WINDOWS_DESKTOP}")"

You can use the variable, like so:

ls -ld "${WINDOWS_DESKTOP}"

-- 
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: scp and ssh 'cat' stalls at 64k bytes

[Voris, Ben via Cygwin]

Using scp from OpenSSH_9.3p1, 30 May 2023, copied a 8317351936 byte file from a 
remote to Cygwin. sha1sum says it arrived correctly.

Windows Firewall is running.

> -Original Message-
> From: Chris Roehrig 
> Sent: 23 June 2023 13:42
> To: cygwin@cygwin.com
> Subject: Re: scp and ssh 'cat' stalls at 64k bytes
> 
> 
> On 2023-06-23 08:28, Brian Inglis wrote:
> > On 2023-06-23 00:26, Chris Roehrig via Cygwin wrote:
> >> I've upgraded cygwin recently (from a much older version) and am
> >> encountering a new problem on all my Win10/WIn11 machines.
> >>
> >> With openssh and pv installed on cygwin (3.4.7-1):
> >>
> >> dd if=/dev/zero bs=1 count=65536 | ssh localhost 'cat > /dev/null'
> >> # works
> >> dd if=/dev/zero bs=1 count=65537 | ssh localhost 'cat > /dev/null'
> >> # stalls (and anything larger)
> >> dd if=/dev/zero bs=1 count=65537 | ssh localhost 'pv > /dev/null'
> >> # replace 'cat' with 'pv' and it works
> >>
> >> This happens with or without Windows Firewall enabled, with any input
> >> > 64k, and also remotely from Linux.
> >> It also seems to affect scp to cygwin which stalls if the file is >= 64k
> >
> > In case equivalent Windows services are running, I check for, shut
> > down, and disable the following Windows services I have seen, or seen
> > warnings about, before trying to start Cygwin services:
> >
> > ssh ssh-agent sshbroker sshproxy sshd sshdbroker sshdproxy
> >
> > Do you take similar precautions on the Windows systems with issues?
> 
> The only service listed is ssh-agent which is disabled and stopped.
> TaskManager did show many zombie/stuck cat.exe  and scp.exe which I
> terminated, but that did not help.   Nor did rebooting.
> 
> I use ssh, rsync, slogin frequently on these machines to/from windows
> and linux and rsync (over ssh) gigabytes of stuff daily to/from Linux
> and other windows machines with no issues.   It is only this case of
> reading more than 64K from stdin over ssh (and scp) that is hanging.
> 
> > Please show at least the output of `uname -srvmo`,
> CYGWIN_NT-10.0-19045 3.4.7-1.x86_64 2023-06-16 14:04 UTC x86_64 Cygwin
> 
> > and if possible provide a text attachment of the output log from
> > running `cygcheck -hrsv > cygcheck.out`, as suggested under the
> > Problem reports link below.
> I've attached the file.
> 
> 
> I take it then you can't replicate this?    Can you confirm whether this
> command works successfully (i.e. exits without hanging):
> 
> dd if=/dev/zero bs=1 count=65537 | ssh localhost 'cat > /dev/null'
> 
> Are you able to 'scp' large files to cygwin?
> 
> 
> It also hangs if I replace 'cat' with 'sed {}' or 'awk {print}', but not
> with 'pv'.   Those all passthrough stdin>stdout and should behave the
> same as cat.  (pv is basically cat with a progress bar which is omitted
> if there's  no controlling terminal like in this case).
> 
> 
> The curious fact that 'pv' works makes me think it is a Cygwin library
> problem and not anything related to firewall/network/Windows.
> 
> I've verified that cat, pv, and sshd all have the same ACLs.  e.g.
> aquila[77]% icacls pv.exe
> pv.exe AQUILA\croehrig:(F)
>      BUILTIN\Administrators:(RX)
>     Everyone:(RX)

-- 
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: Receipt of Payment - $699.99 USD

[Ben Kamen via Cygwin]

On 3/15/23 8:27 AM, Rueban Dhillon via Cygwin wrote:

PayPal

Dear cygwin@cygwin.com,

We are writing to confirm that we have received your payment of $699.99 USD for 
your recent purchase with Coinbase Company. Thank you for your prompt payment.

Please find below the details of your transaction:

Order Number: #5558-6698-2386
Date of Purchase: March 15, 2023
Payment Amount: $699.99 USD



I get these too (don't we all?)

Hilarious AND annoying.





 -Ben

--
Ben Kamen - O.D.T., S.P.
--
Email: ben AT benkamen DOT net http://www.benkamen.net
Cell:  224.619.9006http://www.linkedin.com/in/benkamen
--
NOTICE: All legal disclaimers sent to benkamen.net
or any of its affiliated domains are rendered null and void on
receipt of communications and will be handled/considered as such.


--
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

clang-format and clang-check return 127 and no text

[Voris, Ben via Cygwin]

clang-format --version prints nothing. Its exit code is 127.

This has worked but I haven't used it for at least a few weeks. No idea how 
many packages I've updated since.

I reinstalled all packages whose name contains "clang". No change.

clang-format --version || echo $?
127

strace clang-format
--- Process 26680 created
--- Process 26680 loaded C:\Windows\System32\ntdll.dll at 7ffc1047
--- Process 26680 loaded C:\Windows\System32\kernel32.dll at 7ffc0f19
--- Process 26680 loaded C:\Windows\System32\KernelBase.dll at 7ffc0e1a
--- Process 26680 thread 3632 created
--- Process 26680 thread 15012 created
--- Process 26680 thread 12200 created
--- Process 26680 loaded C:\cygwin64\bin\cygwin1.dll at 7ffb998a
--- Process 26680 loaded C:\cygwin64\bin\cygstdc++-6.dll at 0003eef9
--- Process 26680 loaded C:\cygwin64\bin\cygclangBasic-8.dll at 0003f90b
--- Process 26680 loaded C:\cygwin64\bin\cygLLVMSupport-8.dll at 
0003fc20
--- Process 26680 loaded C:\cygwin64\bin\cygclangFormat-8.dll at 
0003f87d
--- Process 26680 loaded C:\cygwin64\bin\cygclangToolingCore-8.dll at 
0003f73b
--- Process 26680 loaded C:\cygwin64\bin\cygclangRewrite-8.dll at 
0003f83d
--- Process 26680 loaded C:\cygwin64\bin\cyggcc_s-seh-1.dll at 0003f646
--- Process 26680 loaded C:\cygwin64\bin\cygncursesw-10.dll at 0003f017
--- Process 26680 loaded C:\cygwin64\bin\cygLLVMCore-8.dll at 0003fe33
--- Process 26680 loaded C:\cygwin64\bin\cygLLVMMC-8.dll at 0003fd74
--- Process 26680 loaded C:\cygwin64\bin\cygz.dll at 0003ee48
--- Process 26680 loaded C:\cygwin64\bin\cygLLVMDemangle-8.dll at 
0003fe09
--- Process 26680 loaded C:\cygwin64\bin\cygclangToolingInclusions-8.dll at 
0003f739
--- Process 26680 loaded C:\cygwin64\bin\cygclangLex-8.dll at 0003f84f
--- Process 26680 loaded C:\cygwin64\bin\cygclangAST-8.dll at 0003f949
--- Process 26680 loaded C:\cygwin64\bin\cygclangLex-8.dll at 0060
--- Process 26680 unloaded DLL at 0060
--- Process 26680 loaded C:\cygwin64\bin\cygLLVMBinaryFormat-8.dll at 
0003fea9

Then I see a pop-up that says:

The procedure entry point _alloca could not be located in the dynamic link 
library C:\cygwin64\bin\cygLLVMSupport-8.dll

: cygcheck $(whence clang-format)
C:\cygwin64\bin\clang-format.exe
  C:\cygwin64\bin\cygwin1.dll
C:\windows\system32\KERNEL32.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-rtlsupport-l1-1-0.dll
  C:\windows\system32\ntdll.dll
  C:\windows\system32\KERNELBASE.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-processthreads-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-processthreads-l1-1-1.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-heap-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-memory-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-handle-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-synch-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-synch-l1-2-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-file-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-file-l1-2-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-namedpipe-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-datetime-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-sysinfo-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-timezone-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-localization-l1-2-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-processenvironment-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-string-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-debug-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-errorhandling-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-util-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-profile-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-file-l2-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-console-l1-1-0.dll
  C:\Program Files\Amazon 
Corretto\jdk11.0.16_9\bin\api-ms-win-core-console-l1-2-0.dll
  C:\cygwin64\bin\cygstdc++-6.dll
C:\cygwin64\bin\cyggcc_s-seh-1.dll
  C:\cygwin64\bin\cygLLVMSupport-8.dll
C:\cygwin64\bin\cygncursesw-10.dll
C:\cygwin64\bin\cygz.dll

RE: Link of ONC RPC client fails with: undefined references

[Voris, Ben]

Thank you.

This fixed it:

-   $(CC) $^ $(LD_LIBS) -o $@
+   $(CC) $(LD_LIBS) -o $@ $^

Now I'm trying to understand why rpcbind fails at 
/usr/src/debug/rpcbind-1.2.5-1/src/rpcbind.c:287, even when run from an 
elevated command prompt:

268 if((p = getpwnam(id)) == NULL) {
269 syslog(LOG_ERR, "cannot get uid of '%s': %m", id);
270 exit(1);
271 }
...
285 if (setuid(p->pw_uid) == -1) {
286 syslog(LOG_ERR, "setuid to '%s' (%d) failed: 
%m", id, p->pw_uid);
287 exit(1);
288 }

I do find this:

Under "Switching the user context", https://cygwin.com/cygwin-ug-net/ntsec.html 
says

> Windows does not support the concept of these calls in a simple fashion.
> Switching the user context in Windows is generally a tricky process with lots
> of "behind the scenes" magic involved.
>
> \[H\]ow can this \[information\] be used to implement set(e)uid? Well, it
> requires modification of the calling application.

Based on skim of the this source, that implies that this rpcbind would never 
work which doesn't make sense.


> -Original Message-----
> From: Jon Turney 
> Sent: 29 April 2022 05:29
> To: Voris, Ben ; The Cygwin Mailing List 
> 
> Subject: Re: Link of ONC RPC client fails with: undefined references
> 
> On 29/04/2022 04:06, Voris, Ben wrote:
> > I have simple ONC RPC client and server that build on Ubuntu with rpcgen
> "(Ubuntu GLIBC 2.31-0ubuntu9.7) 2.31" (under "5.10.102.1-microsoft-standard-
> WSL2") but fails to build on Cygwin ("3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64
> Cygwin") with rpcgen "(rpcsvc-proto) 1.4".
> >
> > Naively, it appears that Ubuntu has a much newer version (2.31) than Cygwin
> (1.4). Is this the problem?
> >
> > gzip'ed cygcheck output and the test program and makefile are attached.
> >
> > Output of "make all"
> [...]
> > gcc -ltirpc -o objs/date_client objs/date_client.o objs/date_clnt.o
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> objs/date_client.o: in function `date_prog_1':
> > /home/BVoris/git/ONC-rpc-test/src/date_client.c:15: undefined reference to
> `clnt_create'
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> /home/BVoris/git/ONC-rpc-test/src/date_client.c:17: undefined reference to
> `clnt_pcreateerror'
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> /home/BVoris/git/ONC-rpc-test/src/date_client.c:33: undefined reference to
> `clnt_perror'
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> objs/date_clnt.o:date_clnt.c:(.rdata$.refptr.xdr_wrapstring[.refptr.xdr_wrapstr
> ing]+0x0): undefined reference to `xdr_wrapstring'
> 
> I suspect the problem here is due to the position of '-ltirpc' in the
> compiler command line. Moving it to after the .o files might help.
> See
> INVALID URI REMOVED
> _;Iw!!NpxR!mh4II02xebe-
> AOaVrVnhqLMZ184wpNJtizkEmBv2uzw49eZ11dNZZClae3F00QGiI4IjKo7KYcBeP0qGGZVCzgU$
> for details why.


-- 
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

Link of ONC RPC client fails with: undefined references

[Voris, Ben]

I have simple ONC RPC client and server that build on Ubuntu with rpcgen 
"(Ubuntu GLIBC 2.31-0ubuntu9.7) 2.31" (under 
"5.10.102.1-microsoft-standard-WSL2") but fails to build on Cygwin 
("3.3.4(0.341/5/3) 2022-01-31 19:35 x86_64 Cygwin") with rpcgen "(rpcsvc-proto) 
1.4".

Naively, it appears that Ubuntu has a much newer version (2.31) than Cygwin 
(1.4). Is this the problem?

gzip'ed cygcheck output and the test program and makefile are attached.

Output of "make all"

Making RPC header file rpcgen_output/date.h from date.x
mkdir -p rpcgen_output/
rm -f rpcgen_output/date.h
rpcgen -h -o rpcgen_output/date.h date.x
Compiling objs/date_client.o from src/date_client.c
mkdir -p objs/
gcc -c -g -O0 -I ./rpcgen_output/ -oobjs/date_client.o src/date_client.c
Making RPC client stub rpcgen_output/date_clnt.c from date.x
mkdir -p rpcgen_output/
rm -f rpcgen_output/date_clnt.c
rpcgen -l -o rpcgen_output/date_clnt.c date.x
Compiling objs/date_clnt.o from rpcgen_output/date_clnt.c
mkdir -p objs/
gcc -c -g -O0 -I ./rpcgen_output/ -oobjs/date_clnt.o rpcgen_output/date_clnt.c
Making objs/date_client from objs/date_client.o objs/date_clnt.o
gcc -ltirpc -o objs/date_client objs/date_client.o objs/date_clnt.o
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
objs/date_client.o: in function `date_prog_1':
/home/BVoris/git/ONC-rpc-test/src/date_client.c:15: undefined reference to 
`clnt_create'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/src/date_client.c:17: undefined reference to 
`clnt_pcreateerror'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/src/date_client.c:33: undefined reference to 
`clnt_perror'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
objs/date_clnt.o:date_clnt.c:(.rdata$.refptr.xdr_wrapstring[.refptr.xdr_wrapstring]+0x0):
 undefined reference to `xdr_wrapstring'
collect2: error: ld returned 1 exit status
make: *** [Makefile:53: objs/date_client] Error 1

Building the server also fails but with different errors. Output of "make 
objs/date_server":

Compiling objs/date_server.o from src/date_server.c
mkdir -p objs/
gcc -c -g -O0 -I ./rpcgen_output/ -oobjs/date_server.o src/date_server.c
src/date_server.c: In function 'get_remote_date_1_svc':
src/date_server.c:34:30: warning: initialization of 'struct sockaddr_in *' from 
incompatible pointer type 'struct sockaddr_in6 *' [-Wincompatible-pointer-types]
   34 |   struct sockaddr_in *sock = svc_getcaller(
  |  ^
Making RPC server code rpcgen_output/date_svc.c from date.x
mkdir -p rpcgen_output/
rm -f rpcgen_output/date_svc.c
rpcgen -s tcp -o rpcgen_output/date_svc.c date.x
Compiling objs/date_svc.o from rpcgen_output/date_svc.c
mkdir -p objs/
gcc -c -g -O0 -I ./rpcgen_output/ -oobjs/date_svc.o rpcgen_output/date_svc.c
Making objs/date_server from objs/date_server.o objs/date_svc.o
gcc -ltirpc -o objs/date_server objs/date_server.o objs/date_svc.o
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
objs/date_svc.o: in function `date_prog_1':
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:31: undefined reference 
to `svc_sendreply'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:41: undefined reference 
to `svcerr_noproc'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:46: undefined reference 
to `svcerr_decode'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:50: undefined reference 
to `svc_sendreply'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:51: undefined reference 
to `svcerr_systemerr'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
objs/date_svc.o: in function `main':
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:65: undefined reference 
to `pmap_unset'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:67: undefined reference 
to `svctcp_create'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:72: undefined reference 
to `svc_register'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
/home/BVoris/git/ONC-rpc-test/rpcgen_output/date_svc.c:77: undefined reference 
to `svc_run'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
objs/date_svc.o:date_svc.c:(.rdata$.refptr.xdr_wrapstring[.refptr.xdr_wrapstring]+0x0):
 undefined reference to `xdr_wrapstring'
/usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld: 
objs/date_svc.o:date_svc.c:(.rdata$.refptr.xdr_void[.refptr.xdr_void]+0x0): 

RE: curl SFTP transfer from Cygwin on Win10 to Ubuntu 18.04 fails with Unknown host key type: 1835008

[Voris, Ben via Cygwin]

-Original Message-
From: Brian Inglis [mailto:brian.ing...@systematicsw.ab.ca] 
Sent: 24 May 2021 11:09
To: cygwin@cygwin.com
Cc: Voris, Ben 
Subject: Re: curl SFTP transfer from Cygwin on Win10 to Ubuntu 18.04 fails with 
Unknown host key type: 1835008

On 2021-05-17 17:55, Brian Inglis wrote:
> On 2021-05-14 23:47, Brian Inglis wrote:
>> On 2021-05-13 22:40, Voris, Ben via Cygwin wrote:
>>> curl issue https://github.com/curl/curl/issues/7057 was closed with:
>>> "This seems to be purely a libssh2 issue and not a curl one."
>>> Curl reports "libssh2/1.7.0"
>>> On the same system, ssh reports " OpenSSH_8.5p1, OpenSSL 1.1.1f  31 Mar 
>>> 2020"
>>> The curl code in 
>>> https://github.com/curl/curl/blob/master/lib/vssh/libssh2.c has a number of 
>>> defines to control what 
>>> type of host keys it will accept, including LIBSSH2_KNOWNHOST_KEY_ED25519
>>> Was the curl built with this set?
>>> Details are in the curl issue, but here they are again.
>>> Here is the curl failure:
>>> : curl -vvv -s -T t.cpp sftp://bvoris@nucnuc/tmp/t2.cpp 
>>> * STATE: INIT => CONNECT handle 0x800085338; line 1634 (connection #-5000)
>>> * Added connection 0. The cache now contains 1 members
>>> * STATE: CONNECT => RESOLVING handle 0x800085338; line 1680 (connection #0)
>>> * family0 == v4, family1 == v6
>>> *   Trying 192.168.1.5:22...
>>> * STATE: RESOLVING => CONNECTING handle 0x800085338; line 1762 (connection 
>>> #0)
>>> * Connected to nucnuc (192.168.1.5) port 22 (#0)
>>> * STATE: CONNECTING => PROTOCONNECT handle 0x800085338; line 1825 
>>> (connection #0)
>>> * SFTP 0x8000847c8 state change from SSH_STOP to SSH_INIT
>>> * Found host nucnuc in /home/BVoris/.ssh/known_hosts
>>> * Unknown host key type: 1835008
>>> * SFTP 0x8000847c8 state change from SSH_INIT to SSH_SESSION_FREE
>>> * SFTP 0x8000847c8 state change from SSH_SESSION_FREE to SSH_STOP
>>> * multi_done
>>> * The cache now contains 0 members
>>> * SSH DISCONNECT starts now
>>> * SSH DISCONNECT is done
>>> * Closing connection 0
>>> The curl/libcurl version:
>>> curl 7.76.1 (x86_64-pc-cygwin) libcurl/7.76.1 OpenSSL/1.1.1f zlib/1.2.11 
>>> brotli/1.0.9 zstd/1.4.9 libidn2/2.2.0 
>>> libpsl/0.21.0 (+libidn2/2.0.4) libssh2/1.7.0 nghttp2/1.37.0
>>> Release-Date: 2021-04-14
>>> Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap 
>>> ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs 
>>> smtp smtps telnet tftp
>>> Features: alt-svc AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6 
>>> Kerberos Largefile libz Metalink NTLM 
>>> NTLM_WB PSL SPNEGO SSL TLS-SRP TrackMemory UnixSockets zstd
>>> The known_hosts entry from the client:
>>> nucnuc ssh-ed25519 
>>> C3NzaC1lZDI1NTE5ICmjvQ5jehz5Jwt1PDGJBSgcXVhoMRnbn/E2p3srSK+c
>>> curl is run on CYGWIN_NT-10.0 3.2.0(0.340/5/3) 2021-03-29 08:42 x86_64 
>>> Cygwin
>>> The target system has:
>>> OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
>>
>> Looks like it will need libssh2 1.9.0+.
>> The next version 1.9.1 is nearing release incorporating all the updated 
>> support
>> as well as all CVE and other patches.
>>
>> I am working on a couple of build issues, with upstream, and also 32 bit x86 
>> builds.
>>
>> If I can get those resolved, I could adopt libssh2 (also hosted/supported 
>> @haxx.se
>> involving some of the same folks), releasing an update when the new libssh2 
>> release
>> is available, and releasing an updated curl release 2 with the updated 
>> libssh2.

> New libssh2 1.9+ releases are available with latest ciphers and CVE patches,
> and new curl -2 releases are available built with the new libssh2 releases.
> 
> Please upgrade your Cygwin installation, retest, and let us know if you still
> have any issues, or you can now successfully connect.
> 
> After some more Cygwin et al testing of the latest libssh2 upstream repo
> commits and snapshots, the libssh2 project is eager to release the latest
> libssh2 1.9.1, and newer releases of curl will be made available using
> those updates.

This problem no longer occurs in curl 7.770 (x86_64-pc-cygwin) libssh2/1.9.0, 
release date 2021-05-26.


-- 
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

curl SFTP transfer from Cygwin on Win10 to Ubuntu 18.04 fails with Unknown host key type: 1835008

[Voris, Ben via Cygwin]

curl issue https://github.com/curl/curl/issues/7057 was closed with:

"This seems to be purely a libssh2 issue and not a curl one."

Curl reports "libssh2/1.7.0"

On the same system, ssh reports " OpenSSH_8.5p1, OpenSSL 1.1.1f  31 Mar 2020"

The curl code in https://github.com/curl/curl/blob/master/lib/vssh/libssh2.c 
has a number of defines to control what type of host keys it will accept, 
including LIBSSH2_KNOWNHOST_KEY_ED25519

Was the curl built with this set?

Details are in the curl issue, but here they are again.

-

Here is the curl failure:

: curl -vvv -s -T t.cpp sftp://bvoris@nucnuc/tmp/t2.cpp
* STATE: INIT => CONNECT handle 0x800085338; line 1634 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => RESOLVING handle 0x800085338; line 1680 (connection #0)
* family0 == v4, family1 == v6
*   Trying 192.168.1.5:22...
* STATE: RESOLVING => CONNECTING handle 0x800085338; line 1762 (connection #0)
* Connected to nucnuc (192.168.1.5) port 22 (#0)
* STATE: CONNECTING => PROTOCONNECT handle 0x800085338; line 1825 (connection 
#0)
* SFTP 0x8000847c8 state change from SSH_STOP to SSH_INIT
* Found host nucnuc in /home/BVoris/.ssh/known_hosts
* Unknown host key type: 1835008
* SFTP 0x8000847c8 state change from SSH_INIT to SSH_SESSION_FREE
* SFTP 0x8000847c8 state change from SSH_SESSION_FREE to SSH_STOP
* multi_done
* The cache now contains 0 members
* SSH DISCONNECT starts now
* SSH DISCONNECT is done
* Closing connection 0

-

The curl/libcurl version:

curl 7.76.1 (x86_64-pc-cygwin) libcurl/7.76.1 OpenSSL/1.1.1f zlib/1.2.11 
brotli/1.0.9 zstd/1.4.9 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4) 
libssh2/1.7.0 nghttp2/1.37.0
Release-Date: 2021-04-14
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps 
mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6 
Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP 
TrackMemory UnixSockets zstd


-

The known_hosts entry from the client:

nucnuc ssh-ed25519 
C3NzaC1lZDI1NTE5ICmjvQ5jehz5Jwt1PDGJBSgcXVhoMRnbn/E2p3srSK+c

-

curl is run on CYGWIN_NT-10.0 3.2.0(0.340/5/3) 2021-03-29 08:42 x86_64 Cygwin

The target system has:

OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017





-- 
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: [PATCH 09/11] mount.cc: Implement poor-man's cache

[Ben]

On 18-01-2021 12:51, Corinna Vinschen via Cygwin-patches wrote:
> Ok, so hash_prefix reduces the path to a drive letter or the UNC path
> prefix and hashes it.  However, what about partitions mounted to a
> subdir of, say, drive C?  In that case the hashing goes awry, because
> you're comparing with the hash of drive C while the path is actually
> pointing to another partition.
> 
How can I mount a partition as a subdir of drive C?
For some reason I can't:
$ mount /cygdrive/e/Temp/dummy /cygdrive/c/Temp/dummy/dummyone
mount: /cygdrive/c/Temp/dummy/dummyone: Invalid argument

Re: [PATCH v2 4/8] syscalls.cc: Implement non-path_conv dependent _unlink_nt

[Ben]

 FileBasicInformation);
>> +  debug_printf ("NtQueryFileBasicInformation %S: %y",
>> +attr->ObjectName, istatus);
>> +
>> +  if (NT_SUCCESS (istatus))
>> +{
>> +  if (qfbi.FileAttributes & FILE_ATTRIBUTE_READONLY)
>> +{
>> +  //Step 5
>> +  //Remove the readonly flag
>> +  FILE_BASIC_INFORMATION sfbi = { 0 };
>> +  sfbi.FileAttributes = FILE_ATTRIBUTE_ARCHIVE;
>> +  istatus = NtSetInformationFile (fh, , ,
>> +  sizeof sfbi,
>> +  FileBasicInformation);
>> +  debug_printf ("NtSetFileBasicInformation %S: %y",
>> +attr->ObjectName, istatus);
>> +}
>> +
>> +  if (NT_SUCCESS (istatus))
>> +{
>> +  //Step 6a
>> +  //Now, mark the file ready for deletion
>> +  if (has_posix_unlink_semantics)
>> +{
>> +  FILE_DISPOSITION_INFORMATION_EX fdie =
>> +{ FILE_DISPOSITION_DELETE
>> +| FILE_DISPOSITION_POSIX_SEMANTICS };
>> +  istatus = NtSetInformationFile (
>> +  fh, , , sizeof fdie,
>> +  FileDispositionInformationEx);
>> +  debug_printf (
>> +  "NtSetFileDispositionInformationEx %S: %y",
>> +  attr->ObjectName, istatus);
>> +
>> +  if (istatus == STATUS_INVALID_PARAMETER)
>> +has_posix_unlink_semantics = false;
>> +}
>> +
>> +  if (!has_posix_unlink_semantics
>> +  || !NT_SUCCESS (istatus))
>> +{
>> +  //Step 6b
>> +  //This will remove a readonly file (as we have 
>> just cleared that flag)
>> +  //As we don't have posix unlink semantics, this 
>> will still fail if the file is in use.
> 
> Without transaction?
> 
Well, yes, the transaction overhead doesn't weigh up to the unlikeliness of 
failure, I think.
Because even if the delete fails, the attributes are restored. Or, 
very-unlikely-worst-case-scenario:
Both fail and we're left with a file with FILE_ATTRIBUTE_ARCHIVE which means 
the file has been marked for deletion.


>> +static NTSTATUS
>> +_unlink_ntpc_ (path_conv& pc, bool shareable)
> 
> The trailing underscore should be replaced with a descriptive postfix.

What about naming this function _unlink_nt and the original _unlink_nt, 
_unlink_fallback?


>> +{
>> +  OBJECT_ATTRIBUTES attr;
>> +  ULONG eflags = pc.isdir () ? FILE_DIRECTORY_FILE : 
>> FILE_NON_DIRECTORY_FILE;
>> +
>> +  pc.get_object_attr (attr, sec_none_nih);
>> +  NTSTATUS status = _unlink_nt (, eflags);
> 
> Sorry, but I don't grok that.  You already have a path_conv, so what's
> the advantage of calling the unlink version without path_conv and thus,
> without certain check, like the reparse point check, or checks for
> filesystems with quirks, like MVFS?  What about remote filesystems of
> which you don't know nothing, e. g., a Win7 NTFS?  Did you check the
> error codes in this case?
> 
The idea is to - eventually - replace/incorporate the fallback unlink_nt.
But, because I indeed don't know the quirks of all filesystems, I left the 
fallback scenario intact, for now.
No, I have not checked all error codes, I simply don't have all filesystems at 
my disposal, again the reason for keeping the fallback.

The general idea is to forgo path_conv's filesystem checks and just try to 
delete the file,
if it fails, remember and fallback. After these series of commits, some will 
follow
to try and see if we can remove/incorporate the fallback scenario completely.


Ben...

Re: [PATCH v2 7/8] dir.cc: Try unlink_nt first

[Ben]

On 26-01-2021 12:46, Corinna Vinschen via Cygwin-patches wrote:
> 
> So what about /dev, /proc, etc?
> 

The idea was to catch them with pc.isspecial() in unlink_nt.

[PATCH v3 2/8] syscalls.cc: Deduplicate remove

[Ben Wijen]

The remove code is already in the _remove_r function.
So, just call the _remove_r function.
---
 winsup/cygwin/syscalls.cc | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 8651cfade..e6ff0fd7a 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1161,24 +1161,15 @@ _remove_r (struct _reent *, const char *ourname)
   return -1;
 }
 
-  return win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
+  int res = win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
+  syscall_printf ("%R = remove(%s)", res, ourname);
+  return res;
 }
 
 extern "C" int
 remove (const char *ourname)
 {
-  path_conv win32_name (ourname, PC_SYM_NOFOLLOW);
-
-  if (win32_name.error)
-{
-  set_errno (win32_name.error);
-  syscall_printf ("-1 = remove (%s)", ourname);
-  return -1;
-}
-
-  int res = win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
-  syscall_printf ("%R = remove(%s)", res, ourname);
-  return res;
+  return _remove_r (_REENT, ourname);
 }
 
 extern "C" pid_t
-- 
2.30.0

[PATCH v3 1/8] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE

[Ben Wijen]

I think we don't need an extra flag as we can utilize: access & 
FILE_WRITE_ATTRIBUTES
What do you think?


Ben Wijen (1):
  syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE

 winsup/cygwin/ntdll.h |  3 ++-
 winsup/cygwin/syscalls.cc | 22 +++
 winsup/cygwin/wincap.cc   | 11 
 winsup/cygwin/wincap.h| 56 ---
 4 files changed, 53 insertions(+), 39 deletions(-)

-- 
2.30.0

>From 2d0ff6fec10d03c24d11c747852018b7bc1136ac Mon Sep 17 00:00:00 2001
In-Reply-To: <20210122105201.gd810...@calimero.vinschen.de>
References: <20210122105201.gd810...@calimero.vinschen.de>
From: Ben Wijen 
Date: Tue, 17 Dec 2019 15:15:25 +0100
Subject: [PATCH v3 1/8] syscalls.cc: unlink_nt: Try
 FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE

Implement wincap.has_posix_unlink_semantics_with_ignore_readonly and when set
skip setting/clearing of READONLY attribute and instead use
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
---
 winsup/cygwin/ntdll.h |  3 ++-
 winsup/cygwin/syscalls.cc | 22 +++
 winsup/cygwin/wincap.cc   | 11 
 winsup/cygwin/wincap.h| 56 ---
 4 files changed, 53 insertions(+), 39 deletions(-)

diff --git a/winsup/cygwin/ntdll.h b/winsup/cygwin/ntdll.h
index d4f6aaf45..7eee383dd 100644
--- a/winsup/cygwin/ntdll.h
+++ b/winsup/cygwin/ntdll.h
@@ -497,7 +497,8 @@ enum {
   FILE_DISPOSITION_DELETE  = 0x01,
   FILE_DISPOSITION_POSIX_SEMANTICS = 0x02,
   FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK   = 0x04,
-  FILE_DISPOSITION_ON_CLOSE= 0x08
+  FILE_DISPOSITION_ON_CLOSE= 0x08,
+  FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE   = 0x10,
 };
 
 enum
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 7044ea903..8651cfade 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -719,7 +719,7 @@ _unlink_nt (path_conv , bool shareable)
 
   pc.get_object_attr (attr, sec_none_nih);
 
-  /* First check if we can use POSIX unlink semantics: W10 1709++, local NTFS.
+  /* First check if we can use POSIX unlink semantics: W10 1709+, local NTFS.
  With POSIX unlink semantics the entire job gets MUCH easier and faster.
  Just try to do it and if it fails, it fails. */
   if (wincap.has_posix_unlink_semantics ()
@@ -727,20 +727,18 @@ _unlink_nt (path_conv , bool shareable)
 {
   FILE_DISPOSITION_INFORMATION_EX fdie;
 
-  if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
+  /* POSIX unlink semantics are nice, but they still fail if the file has
+the R/O attribute set. If so, ignoring might be an option: W10 1809+
+Removing the file is very much a safe bet afterwards, so, no
+transaction. */
+  if ((pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
+  && !wincap.has_posix_unlink_semantics_with_ignore_readonly ())
access |= FILE_WRITE_ATTRIBUTES;
   status = NtOpenFile (, access, , , FILE_SHARE_VALID_FLAGS,
   flags);
   if (!NT_SUCCESS (status))
goto out;
-  /* Why didn't the devs add a FILE_DELETE_IGNORE_READONLY_ATTRIBUTE
-flag just like they did with FILE_LINK_IGNORE_READONLY_ATTRIBUTE
-and FILE_LINK_IGNORE_READONLY_ATTRIBUTE???
-
- POSIX unlink semantics are nice, but they still fail if the file
-has the R/O attribute set.  Removing the file is very much a safe
-bet afterwards, so, no transaction. */
-  if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
+  if (access & FILE_WRITE_ATTRIBUTES)
{
  status = NtSetAttributesFile (fh, pc.file_attributes ()
& ~FILE_ATTRIBUTE_READONLY);
@@ -751,10 +749,12 @@ _unlink_nt (path_conv , bool shareable)
}
}
   fdie.Flags = FILE_DISPOSITION_DELETE | FILE_DISPOSITION_POSIX_SEMANTICS;
+  if (wincap.has_posix_unlink_semantics_with_ignore_readonly ())
+fdie.Flags |= FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE;
   status = NtSetInformationFile (fh, , , sizeof fdie,
 FileDispositionInformationEx);
   /* Restore R/O attribute in case we have multiple hardlinks. */
-  if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
+  if (access & FILE_WRITE_ATTRIBUTES)
NtSetAttributesFile (fh, pc.file_attributes ());
   NtClose (fh);
   /* Trying to delete in-use executables and DLLs using
diff --git a/winsup/cygwin/wincap.cc b/winsup/cygwin/wincap.cc
index b18e732cd..635e0892b 100644
--- a/winsup/cygwin/wincap.cc
+++ b/winsup/cygwin/wincap.cc
@@ -38,6 +38,7 @@ wincaps wincap_vista __attribute__((section 
(".cygwin_dll_common"), shared)) = {
 has_unbiased_interrupt_time:false,
 has_pr

[PATCH v2 6/8] syscalls.cc: Expose shallow-pathconv unlink_nt

[Ben Wijen]

Not having to query file information improves unlink speed.
---
 winsup/cygwin/syscalls.cc | 78 ++-
 1 file changed, 52 insertions(+), 26 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index ab0c4c2d6..b5ab6ac5e 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1272,6 +1272,28 @@ _unlink_ntpc_ (path_conv& pc, bool shareable)
   return status;
 }
 
+NTSTATUS
+unlink_nt (const char *ourname, ULONG eflags)
+{
+  uint32_t opt = PC_SYM_NOFOLLOW | PC_SKIP_SYM_CHECK | PC_SKIP_FS_CHECK;
+  if (!(eflags & FILE_NON_DIRECTORY_FILE))
+opt &= ~PC_SKIP_FS_CHECK;
+
+  path_conv pc (ourname, opt, NULL);
+  if (pc.error || pc.isspecial ())
+return STATUS_CANNOT_DELETE;
+
+  OBJECT_ATTRIBUTES attr;
+  PUNICODE_STRING ntpath = pc.get_nt_native_path ();
+  InitializeObjectAttributes(, ntpath, 0, NULL, NULL);
+  NTSTATUS status = _unlink_nt (, eflags);
+
+  if (!(eflags & FILE_NON_DIRECTORY_FILE))
+status = _unlink_nt_post_dir_check (status, , pc);
+
+  return status;
+}
+
 NTSTATUS
 unlink_ntpc (path_conv )
 {
@@ -1289,37 +1311,41 @@ unlink (const char *ourname)
 {
   int res = -1;
   dev_t devn;
-  NTSTATUS status;
+  NTSTATUS status = unlink_nt (ourname, FILE_NON_DIRECTORY_FILE);
 
-  path_conv win32_name (ourname, PC_SYM_NOFOLLOW, stat_suffixes);
+  if (!NT_SUCCESS (status))
+  {
+path_conv win32_name (ourname, PC_SYM_NOFOLLOW, stat_suffixes);
 
-  if (win32_name.error)
-{
-  set_errno (win32_name.error);
-  goto done;
-}
+if (win32_name.error)
+  {
+set_errno (win32_name.error);
+goto done;
+  }
 
-  devn = win32_name.get_device ();
-  if (isproc_dev (devn))
-{
-  set_errno (EROFS);
-  goto done;
-}
+devn = win32_name.get_device ();
+if (isproc_dev (devn))
+  {
+set_errno (EROFS);
+goto done;
+  }
 
-  if (!win32_name.exists ())
-{
-  debug_printf ("unlinking a nonexistent file");
-  set_errno (ENOENT);
-  goto done;
-}
-  else if (win32_name.isdir ())
-{
-  debug_printf ("unlinking a directory");
-  set_errno (EISDIR);
-  goto done;
-}
+if (!win32_name.exists ())
+  {
+debug_printf ("unlinking a nonexistent file");
+set_errno (ENOENT);
+goto done;
+  }
+else if (win32_name.isdir ())
+  {
+debug_printf ("unlinking a directory");
+set_errno (EISDIR);
+goto done;
+  }
+
+status = unlink_ntpc (win32_name);
+  }
 
-  status = unlink_ntpc (win32_name);
   if (NT_SUCCESS (status))
 res = 0;
   else
-- 
2.30.0

[PATCH v2 8/8] fhandler_disk_file.cc: Use path_conv's IndexNumber

[Ben Wijen]

path_conv already knows the IndexNumber, so just use it.

This commit also fixes the potential handle leak.
---
 winsup/cygwin/fhandler_disk_file.cc | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index fe04f832b..39f914a59 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -2029,9 +2029,6 @@ readdir_get_ino (const char *path, bool dot_dot)
 {
   char *fname;
   struct stat st;
-  HANDLE hdl;
-  OBJECT_ATTRIBUTES attr;
-  IO_STATUS_BLOCK io;
   ino_t ino = 0;
 
   if (dot_dot)
@@ -2044,26 +2041,17 @@ readdir_get_ino (const char *path, bool dot_dot)
   path = fname;
 }
   path_conv pc (path, PC_SYM_NOFOLLOW | PC_POSIX | PC_KEEP_HANDLE);
-  if (pc.isspecial ())
+  if (pc.isgood_inode (pc.fai ()->InternalInformation.IndexNumber.QuadPart))
+ino = pc.fai ()->InternalInformation.IndexNumber.QuadPart;
+  else if (pc.isspecial ())
 {
   if (!stat_worker (pc, ))
ino = st.st_ino;
 }
-  else if (!pc.hasgood_inode ())
+
+  if (!ino)
 ino = hash_path_name (0, pc.get_nt_native_path ());
-  else if ((hdl = pc.handle ()) != NULL
-  || NT_SUCCESS (NtOpenFile (, READ_CONTROL,
- pc.get_object_attr (attr, sec_none_nih),
- , FILE_SHARE_VALID_FLAGS,
- FILE_OPEN_FOR_BACKUP_INTENT
- | (pc.is_known_reparse_point ()
- ? FILE_OPEN_REPARSE_POINT : 0)))
- )
-{
-  ino = pc.get_ino_by_handle (hdl);
-  if (!ino)
-   ino = hash_path_name (0, pc.get_nt_native_path ());
-}
+
   return ino;
 }
 
-- 
2.30.0

[PATCH v2 7/8] dir.cc: Try unlink_nt first

[Ben Wijen]

Speedup deletion of directories.
---
 winsup/cygwin/dir.cc | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index 7762557d6..470f83aee 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -22,6 +22,8 @@ details. */
 #include "cygtls.h"
 #include "tls_pbuf.h"
 
+extern NTSTATUS unlink_nt (const char *ourname, ULONG eflags);
+
 extern "C" int
 dirfd (DIR *dir)
 {
@@ -398,6 +400,14 @@ rmdir (const char *dir)
  if (msdos && p == dir + 1 && isdrive (dir))
p[1] = '\\';
}
+  if (has_dot_last_component (dir, false)) {
+set_errno (EINVAL);
+__leave;
+  }
+  if (NT_SUCCESS (unlink_nt (dir, FILE_DIRECTORY_FILE))) {
+res = 0;
+__leave;
+  }
   if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW)))
__leave;   /* errno already set */;
 
@@ -408,8 +418,6 @@ rmdir (const char *dir)
}
   else if (!fh->exists ())
set_errno (ENOENT);
-  else if (has_dot_last_component (dir, false))
-   set_errno (EINVAL);
   else if (!fh->rmdir ())
res = 0;
   delete fh;
-- 
2.30.0

[PATCH v2 5/8] path.cc: Allow to skip filesystem checks

[Ben Wijen]

When file attributes are of no concern, there is no point to query them.
This can greatly speedup code which doesn't need it.

The idea is to have a shallow path conversion with only minimal information.

The upcoming unlink_nt for example, first tries a path without filesystem
checks, then - if necessary - retries with filesystem checks.
---
 winsup/cygwin/path.cc | 7 ---
 winsup/cygwin/path.h  | 2 ++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index abd3687df..441fe113b 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -627,7 +627,7 @@ path_conv::check (const char *src, unsigned opt,
   char *pathbuf = tp.c_get ();
   char *tmp_buf = tp.t_get ();
   char *THIS_path = tp.c_get ();
-  symlink_info sym;
+  symlink_info sym = { 0 };
   bool need_directory = 0;
   bool add_ext = false;
   bool is_relpath;
@@ -931,7 +931,8 @@ path_conv::check (const char *src, unsigned opt,
 
 is_fs_via_procsys:
 
- symlen = sym.check (full_path, suff, fs, conv_handle);
+ if (!(opt & PC_SKIP_SYM_CHECK))
+   symlen = sym.check (full_path, suff, fs, conv_handle);
 
 is_virtual_symlink:
 
@@ -1172,7 +1173,7 @@ path_conv::check (const char *src, unsigned opt,
  return;
}
 
-  if (dev.isfs ())
+  if (!(opt & PC_SKIP_FS_CHECK) && dev.isfs ())
{
  /* If FS hasn't been checked already in symlink_info::check,
 do so now. */
diff --git a/winsup/cygwin/path.h b/winsup/cygwin/path.h
index 62bd5ddd5..5821cdf57 100644
--- a/winsup/cygwin/path.h
+++ b/winsup/cygwin/path.h
@@ -59,6 +59,8 @@ enum pathconv_arg
   PC_KEEP_HANDLE= _BIT (12),   /* keep handle for later stat calls */
   PC_NO_ACCESS_CHECK= _BIT (13),   /* helper flag for error check */
   PC_SYM_NOFOLLOW_DIR   = _BIT (14),   /* don't follow a trailing slash */
+  PC_SKIP_SYM_CHECK = _BIT (15),   /* skip symlink_info::check */
+  PC_SKIP_FS_CHECK  = _BIT (16),   /* skip fs::update check */
   PC_DONT_USE   = _BIT (31)/* conversion to signed happens. */
 };
 
-- 
2.30.0

[PATCH v2 4/8] syscalls.cc: Implement non-path_conv dependent _unlink_nt

[Ben Wijen]

Implement _unlink_nt: wich does not depend on patch_conv
---
 winsup/cygwin/fhandler_disk_file.cc |   4 +-
 winsup/cygwin/forkable.cc   |   4 +-
 winsup/cygwin/syscalls.cc   | 211 ++--
 3 files changed, 200 insertions(+), 19 deletions(-)

diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 07f9c513a..fe04f832b 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1837,7 +1837,7 @@ fhandler_disk_file::mkdir (mode_t mode)
 int
 fhandler_disk_file::rmdir ()
 {
-  extern NTSTATUS unlink_nt (path_conv );
+  extern NTSTATUS unlink_ntpc (path_conv );
 
   if (!pc.isdir ())
 {
@@ -1850,7 +1850,7 @@ fhandler_disk_file::rmdir ()
   return -1;
 }
 
-  NTSTATUS status = unlink_nt (pc);
+  NTSTATUS status = unlink_ntpc (pc);
 
   if (!NT_SUCCESS (status))
 {
diff --git a/winsup/cygwin/forkable.cc b/winsup/cygwin/forkable.cc
index 350a95c3e..bd7421bf5 100644
--- a/winsup/cygwin/forkable.cc
+++ b/winsup/cygwin/forkable.cc
@@ -29,7 +29,7 @@ details. */
 
 /* Allow concurrent processes to use the same dll or exe
  * via their hardlink while we delete our hardlink. */
-extern NTSTATUS unlink_nt_shareable (path_conv );
+extern NTSTATUS unlink_ntpc_shareable (path_conv );
 
 #define MUTEXSEP L"@"
 #define PATHSEP L"\\"
@@ -132,7 +132,7 @@ rmdirs (WCHAR ntmaxpathbuf[NT_MAX_PATH])
  RtlInitUnicodeString (, ntmaxpathbuf);
 
  path_conv pc ();
- unlink_nt_shareable (pc); /* move to bin */
+ unlink_ntpc_shareable (pc); /* move to bin */
}
 
  if (!pfdi->NextEntryOffset)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index b220bedae..ab0c4c2d6 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -491,7 +491,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   break;
 case STATUS_DIRECTORY_NOT_EMPTY:
   /* Uh oh!  This was supposed to be avoided by the check_dir_not_empty
-test in unlink_nt, but given that the test isn't atomic, this *can*
+test in unlink_ntpc, but given that the test isn't atomic, this *can*
 happen.  Try to move the dir back ASAP. */
   pfri->RootDirectory = NULL;
   pfri->FileNameLength = pc.get_nt_native_path ()->Length;
@@ -501,7 +501,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   if (NT_SUCCESS (NtSetInformationFile (fh, , pfri, frisiz,
FileRenameInformation)))
{
- /* Give notice to unlink_nt and leave immediately.  This avoids
+ /* Give notice to unlink_ntpc and leave immediately.  This avoids
 closing the handle, which might still be used if called from
 the rm -r workaround code. */
  bin_stat = dir_not_empty;
@@ -545,7 +545,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   if ((access & FILE_WRITE_ATTRIBUTES) && NT_SUCCESS (status) && !pc.isdir ())
 NtSetAttributesFile (fh, pc.file_attributes ());
   NtClose (fh);
-  fh = NULL; /* So unlink_nt doesn't close the handle twice. */
+  fh = NULL; /* So unlink_ntpc doesn't close the handle twice. */
   /* On success or when trying to unlink a directory we just return here.
  The below code only works for files.  It also fails on NFS. */
   if (NT_SUCCESS (status) || pc.isdir () || pc.fs_is_nfs ())
@@ -695,7 +695,157 @@ _unlink_nt_post_dir_check (NTSTATUS status, 
POBJECT_ATTRIBUTES attr, const path_
 }
 
 static NTSTATUS
-_unlink_nt (path_conv , bool shareable)
+_unlink_nt (POBJECT_ATTRIBUTES attr, ULONG eflags)
+{
+  static bool has_posix_unlink_semantics =
+  wincap.has_posix_unlink_semantics ();
+  static bool has_posix_unlink_semantics_with_ignore_readonly =
+  wincap.has_posix_unlink_semantics_with_ignore_readonly ();
+
+  HANDLE fh;
+  ACCESS_MASK access = DELETE;
+  IO_STATUS_BLOCK io;
+  ULONG flags = FILE_OPEN_REPARSE_POINT | FILE_OPEN_FOR_BACKUP_INTENT
+  | FILE_DELETE_ON_CLOSE | eflags;
+  NTSTATUS fstatus, istatus = STATUS_SUCCESS;
+
+  syscall_printf("Trying to delete %S, isdir = %d", attr->ObjectName,
+ eflags == FILE_DIRECTORY_FILE);
+
+  //FILE_DELETE_ON_CLOSE icw FILE_DIRECTORY_FILE only works when directory is 
empty
+  //-> We must assume directory not empty, therefore only do this for regular 
files.
+  if (eflags & FILE_NON_DIRECTORY_FILE)
+{
+  //Step 1
+  //If the file is not 'in use' and not 'readonly', this should just work.
+  fstatus = NtOpenFile (, access, attr, , FILE_SHARE_DELETE, flags);
+  debug_printf ("NtOpenFile %S: %y", attr->ObjectName, fstatus);
+}
+
+  if (!(eflags & FILE_NON_DIRECTORY_FILE)// Workaround for the 
non-empty-dir issue
+  || fstatus == STATUS_SHARING_VIOLATION // The file is 'in use'
+  || fstatus == STATUS_CANNOT_DELETE)// The file is 'readonly'
+{
+  //Step 2
+   

[PATCH v2 3/8] Cygwin: Move post-dir unlink check

[Ben Wijen]

Move post-dir unlink check from fhandler_disk_file::rmdir to
_unlink_nt_post_dir_check

If a directory is not removed through fhandler_disk_file::rmdir
we can now make sure the post dir check is performed.
---
 winsup/cygwin/fhandler_disk_file.cc | 20 
 winsup/cygwin/syscalls.cc   | 28 
 2 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 885b59161..07f9c513a 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1852,26 +1852,6 @@ fhandler_disk_file::rmdir ()
 
   NTSTATUS status = unlink_nt (pc);
 
-  /* Check for existence of remote dirs after trying to delete them.
- Two reasons:
- - Sometimes SMB indicates failure when it really succeeds.
- - Removing a directory on a Samba drive using an old Samba version
-   sometimes doesn't return an error, if the directory can't be removed
-   because it's not empty. */
-  if (isremote ())
-{
-  OBJECT_ATTRIBUTES attr;
-  FILE_BASIC_INFORMATION fbi;
-  NTSTATUS q_status;
-
-  q_status = NtQueryAttributesFile (pc.get_object_attr (attr, 
sec_none_nih),
-   );
-  if (!NT_SUCCESS (status) && q_status == STATUS_OBJECT_NAME_NOT_FOUND)
-   status = STATUS_SUCCESS;
-  else if (pc.fs_is_samba ()
-  && NT_SUCCESS (status) && NT_SUCCESS (q_status))
-   status = STATUS_DIRECTORY_NOT_EMPTY;
-}
   if (!NT_SUCCESS (status))
 {
   __seterrno_from_nt_status (status);
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 54b065733..b220bedae 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -670,6 +670,30 @@ check_dir_not_empty (HANDLE dir, path_conv )
   return STATUS_SUCCESS;
 }
 
+static NTSTATUS
+_unlink_nt_post_dir_check (NTSTATUS status, POBJECT_ATTRIBUTES attr, const 
path_conv )
+{
+  /* Check for existence of remote dirs after trying to delete them.
+ Two reasons:
+ - Sometimes SMB indicates failure when it really succeeds.
+ - Removing a directory on a Samba drive using an old Samba version
+   sometimes doesn't return an error, if the directory can't be removed
+   because it's not empty. */
+  if (pc.isremote ())
+{
+  FILE_BASIC_INFORMATION fbi;
+  NTSTATUS q_status;
+
+  q_status = NtQueryAttributesFile (attr, );
+  if (!NT_SUCCESS (status) && q_status == STATUS_OBJECT_NAME_NOT_FOUND)
+  status = STATUS_SUCCESS;
+  else if (pc.fs_is_samba ()
+   && NT_SUCCESS (status) && NT_SUCCESS (q_status))
+  status = STATUS_DIRECTORY_NOT_EMPTY;
+}
+  return status;
+}
+
 static NTSTATUS
 _unlink_nt (path_conv , bool shareable)
 {
@@ -1059,6 +1083,10 @@ out:
   /* Stop transaction if we started one. */
   if (trans)
 stop_transaction (status, old_trans, trans);
+
+  if (pc.isdir ())
+status = _unlink_nt_post_dir_check (status, , pc);
+
   syscall_printf ("%S, return status = %y", pc.get_nt_native_path (), status);
   return status;
 }
-- 
2.30.0

[PATCH v2 2/8] syscalls.cc: Deduplicate remove

[Ben Wijen]

The remove code is already in the _remove_r function.
So, just call the _remove_r function.
---
 winsup/cygwin/syscalls.cc | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 2e50ad7d5..54b065733 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1133,24 +1133,15 @@ _remove_r (struct _reent *, const char *ourname)
   return -1;
 }
 
-  return win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
+  int res = win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
+  syscall_printf ("%R = remove(%s)", res, ourname);
+  return res;
 }
 
 extern "C" int
 remove (const char *ourname)
 {
-  path_conv win32_name (ourname, PC_SYM_NOFOLLOW);
-
-  if (win32_name.error)
-{
-  set_errno (win32_name.error);
-  syscall_printf ("-1 = remove (%s)", ourname);
-  return -1;
-}
-
-  int res = win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
-  syscall_printf ("%R = remove(%s)", res, ourname);
-  return res;
+  return _remove_r(_REENT, ourname);
 }
 
 extern "C" pid_t
-- 
2.30.0

[PATCH v2 1/8] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE

[Ben Wijen]

Implement wincap.has_posix_unlink_semantics_with_ignore_readonly and when set
skip setting/clearing of READONLY attribute and instead use
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
---
 winsup/cygwin/ntdll.h |  3 ++-
 winsup/cygwin/syscalls.cc | 14 +-
 winsup/cygwin/wincap.cc   | 11 
 winsup/cygwin/wincap.h| 56 ---
 4 files changed, 49 insertions(+), 35 deletions(-)

diff --git a/winsup/cygwin/ntdll.h b/winsup/cygwin/ntdll.h
index d4f6aaf45..7eee383dd 100644
--- a/winsup/cygwin/ntdll.h
+++ b/winsup/cygwin/ntdll.h
@@ -497,7 +497,8 @@ enum {
   FILE_DISPOSITION_DELETE  = 0x01,
   FILE_DISPOSITION_POSIX_SEMANTICS = 0x02,
   FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK   = 0x04,
-  FILE_DISPOSITION_ON_CLOSE= 0x08
+  FILE_DISPOSITION_ON_CLOSE= 0x08,
+  FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE   = 0x10,
 };
 
 enum
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 4742c6653..2e50ad7d5 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -709,14 +709,11 @@ _unlink_nt (path_conv , bool shareable)
   flags);
   if (!NT_SUCCESS (status))
goto out;
-  /* Why didn't the devs add a FILE_DELETE_IGNORE_READONLY_ATTRIBUTE
-flag just like they did with FILE_LINK_IGNORE_READONLY_ATTRIBUTE
-and FILE_LINK_IGNORE_READONLY_ATTRIBUTE???
-
- POSIX unlink semantics are nice, but they still fail if the file
+  /* POSIX unlink semantics are nice, but they still fail if the file
 has the R/O attribute set.  Removing the file is very much a safe
 bet afterwards, so, no transaction. */
-  if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
+  if (!wincap.has_posix_unlink_semantics_with_ignore_readonly ()
+  && (pc.file_attributes () & FILE_ATTRIBUTE_READONLY))
{
  status = NtSetAttributesFile (fh, pc.file_attributes ()
& ~FILE_ATTRIBUTE_READONLY);
@@ -727,10 +724,13 @@ _unlink_nt (path_conv , bool shareable)
}
}
   fdie.Flags = FILE_DISPOSITION_DELETE | FILE_DISPOSITION_POSIX_SEMANTICS;
+  if(wincap.has_posix_unlink_semantics_with_ignore_readonly ())
+  fdie.Flags |= FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE;
   status = NtSetInformationFile (fh, , , sizeof fdie,
 FileDispositionInformationEx);
   /* Restore R/O attribute in case we have multiple hardlinks. */
-  if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
+  if (!wincap.has_posix_unlink_semantics_with_ignore_readonly ()
+  && (pc.file_attributes () & FILE_ATTRIBUTE_READONLY))
NtSetAttributesFile (fh, pc.file_attributes ());
   NtClose (fh);
   /* Trying to delete in-use executables and DLLs using
diff --git a/winsup/cygwin/wincap.cc b/winsup/cygwin/wincap.cc
index b18e732cd..635e0892b 100644
--- a/winsup/cygwin/wincap.cc
+++ b/winsup/cygwin/wincap.cc
@@ -38,6 +38,7 @@ wincaps wincap_vista __attribute__((section 
(".cygwin_dll_common"), shared)) = {
 has_unbiased_interrupt_time:false,
 has_precise_interrupt_time:false,
 has_posix_unlink_semantics:false,
+has_posix_unlink_semantics_with_ignore_readonly:false,
 has_case_sensitive_dirs:false,
 has_posix_rename_semantics:false,
 no_msv1_0_s4u_logon_in_wow64:true,
@@ -72,6 +73,7 @@ wincaps wincap_7 __attribute__((section 
(".cygwin_dll_common"), shared)) = {
 has_unbiased_interrupt_time:true,
 has_precise_interrupt_time:false,
 has_posix_unlink_semantics:false,
+has_posix_unlink_semantics_with_ignore_readonly:false,
 has_case_sensitive_dirs:false,
 has_posix_rename_semantics:false,
 no_msv1_0_s4u_logon_in_wow64:true,
@@ -106,6 +108,7 @@ wincaps wincap_8 __attribute__((section 
(".cygwin_dll_common"), shared)) = {
 has_unbiased_interrupt_time:true,
 has_precise_interrupt_time:false,
 has_posix_unlink_semantics:false,
+has_posix_unlink_semantics_with_ignore_readonly:false,
 has_case_sensitive_dirs:false,
 has_posix_rename_semantics:false,
 no_msv1_0_s4u_logon_in_wow64:false,
@@ -140,6 +143,7 @@ wincaps wincap_8_1 __attribute__((section 
(".cygwin_dll_common"), shared)) = {
 has_unbiased_interrupt_time:true,
 has_precise_interrupt_time:false,
 has_posix_unlink_semantics:false,
+has_posix_unlink_semantics_with_ignore_readonly:false,
 has_case_sensitive_dirs:false,
 has_posix_rename_semantics:false,
 no_msv1_0_s4u_logon_in_wow64:false,
@@ -174,6 +178,7 @@ wincaps  wincap_10_1507 __attribute__((section 
(".cygwin_dll_common"), shared))
 has_unbiased_interrupt_time:true,
 has_precise_interrupt_time:true,
 has_posix_unlink_semantics:false,
+has_posix_unlink_semantics_with_ignore_readonly:false,
 

[PATCH v2 0/8] Improve rm speed

[Ben Wijen]

Hi,

I think I got all remarks, please let me know if I missed something.

I'm still thinking on a better way to use fs_info::update cache,
but it requires more testing.


Thank you,

Ben Wijen (8):
  syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
  syscalls.cc: Deduplicate remove
  Cygwin: Move post-dir unlink check
  syscalls.cc: Implement non-path_conv dependent _unlink_nt
  path.cc: Allow to skip filesystem checks
  syscalls.cc: Expose shallow-pathconv unlink_nt
  dir.cc: Try unlink_nt first
  fhandler_disk_file.cc: Use path_conv's IndexNumber

 winsup/cygwin/dir.cc|  12 +-
 winsup/cygwin/fhandler_disk_file.cc |  48 +---
 winsup/cygwin/forkable.cc   |   4 +-
 winsup/cygwin/ntdll.h   |   3 +-
 winsup/cygwin/path.cc   |   7 +-
 winsup/cygwin/path.h|   2 +
 winsup/cygwin/syscalls.cc   | 346 +++-
 winsup/cygwin/wincap.cc |  11 +
 winsup/cygwin/wincap.h  |  56 ++---
 9 files changed, 354 insertions(+), 135 deletions(-)

-- 
2.30.0

Re: [PATCH 11/11] dir.cc: Try unlink_nt first

[Ben]

On 18-01-2021 18:07, Ben wrote:
> 
> Have I missed something else?
> 
Alright, I now see unlink uses isproc_dev and rmdir uses isdev_dev.

Is this correct?
Why are files and directories handled differently?

Anyway, I will add isdev_dev to the new unlink_nt

Ben...

Re: [PATCH 08/11] path.cc: Allow to skip filesystem checks

[Ben]

On 18-01-2021 12:36, Corinna Vinschen via Cygwin-patches wrote:
> On Jan 15 14:45, Ben Wijen wrote:
> 
> Without any code setting the flag, this doesn't seem to make any
> sense.  At least the commit message should reflect on the reasons
> for this change.
> 
Something like this:
path.cc: Allow to skip filesystem checks

When file attributes are of no concern, there is no point to query them.
This can greatly speedup code which doesn't need it.

For example, this can be used to try a path without filesystem checks first
and try again with filesystem checks


If you want, I can also squash some of these related commits.

Ben...

Re: [PATCH 11/11] dir.cc: Try unlink_nt first

[Ben]

On 18-01-2021 13:13, Corinna Vinschen via Cygwin-patches wrote:
> 
> Your code is skipping the safety checks and the has_dot_last_component()
> check.  The latter implements a check required by POSIX.  Skipping
> it introduces an incompatibility, see man 2 rmdir.
> 

Yes, I missed has_dot_last_component completely.

As for the other checks:
dir.cc: 404: fh->error ():
* Done in unlink_nt
dir.cc: 409: fh->exists ():
* Done in _unlink_nt through NtOpenFile, which will return either
  STATUS_OBJECT_NAME_NOT_FOUND or STATUS_OBJECT_PATH_NOT_FOUND,
  both of which resolve to ENOENT
dir.cc: 413: isdev_dev (fh->dev ()):
* Done in unlink_nt
fhandler_siak_file.cc: 1842:  if (!pc.isdir ())
* Done in _unlink_nt through NtOpenFile with flags FILE_DIRECTORY_FILE
  and FILE_NON_DIRECTORY_FILE which will return STATUS_NOT_A_DIRECTORY
  and STATUS_FILE_IS_A_DIRECTORY respectively.

Have I missed something else?

Also, I think it's better to have isdev_dev (fh->dev ()) return EROFS,
which is the same as unlink.

Re: [PATCH 01/11] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE first

[Ben]

> 
> I'm sure, but that code path is called on non-remote ntfs only anyway.
> 

Ofcourse, I was thinking about the new _unlink_nt...

Re: [PATCH 02/11] syscalls.cc: Deduplicate _remove_r

[Ben]

On 18-01-2021 15:49, Corinna Vinschen via Cygwin-patches wrote:
> 
> Care to send the resulting patch?
> 

Will send with next patch-set.

Ben...

Re: [PATCH 05/11] Cygwin: Move post-dir unlink check

[Ben]

On 18-01-2021 12:08, Corinna Vinschen via Cygwin-patches wrote:
> On Jan 15 14:45, Ben Wijen wrote:
>> Move post-dir unlink check from
>> fhandler_disk_file::rmdir to _unlink_nt
> 
> Why?  It's not much of a problem, codewise, but the commit message
> could be improved here.
> 
Something like this?
Cygwin: Move post-dir unlink check

Move post-dir unlink check from
fhandler_disk_file::rmdir to _unlink_nt

This helps in two ways:
* Now all checks are in one place
* Even if a directory is removed through
  _unlink_nt, but not rmdir, the return
  value can be trusted.

Re: [PATCH 01/11] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE first

[Ben]

On 18-01-2021 13:22, Corinna Vinschen via Cygwin-patches wrote:
> On Jan 18 13:11, Ben wrote:
>>
>>
>> On 18-01-2021 11:45, Corinna Vinschen via Cygwin-patches wrote:
>>> Rather than calling NtSetInformationFile here again, we should rather
>>> just skip the transaction stuff on 1809 and later.  I'd suggest adding
>>> another wincap flag like, say, "has_posix_ro_override", being true
>>> for 1809 and later.  Then we can skip the transaction handling if
>>> wincap.has_posix_ro_override () and just add the
>>> FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE flag to fdie.Flags, if
>>> it's available.
>>
>> Hmmm, I'm not sure if I follow you: This extra NtSetInformationFile is not
>> related to the transaction stuff?
> 
> Right, sorry.  I meant the
> 
>   if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
> 
> bracketed code in fact.  What I meant is to keep it at
> 
>   open
>   if (ro)
> setattributes
>   setinformation
>   ...
> 
> and only add the required additional flag.

Ah, yes I understand. The extra NtSetInformation was there for
the fallback without FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE

I have seen bordercases, but I have not seen NtSetInformation fail
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE and succeed without.
Even if it would, Your suggestion does save a bunch of code...

> 
> 
>> Also I have seen NtSetInformationFile fail with STATUS_INVALID_PARAMETER.
> 
> That should only occur on pre-1809 then, and adding the extra wincap
> would fix that.

Do note: This can also happen post-1809 with a driver that hasn't implemented 
it yet.

> 
>> So a retry without FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE is valid here.
> 
> That would be a border case which might then occur with the
> FILE_DISPOSITION_POSIX_SEMANTICS flag, too.  The current code falls
> through anyway, that should be sufficient, right?

Yes, the existing fallback, should be sufficient.

> 
>>
>> I have thought about adding 
>> wincap.has_posix_unlink_semantics_with_ignore_readonly
>> but it is equal to wincap.has_posix_rename_semantics so I didn't bother 
>> adding it.
> 
> It doesn't hurt to add another flag with the same values.  It's better
> readable in context, which easily makes up for the extra bit :)

Ok, will do.

> 
> 
> Corinna
> 

Re: [PATCH 02/11] syscalls.cc: Deduplicate _remove_r

[Ben]

On 18-01-2021 14:04, Corinna Vinschen via Cygwin-patches wrote:
> What about this instead?  It should be better optimizable:
> 
Hmmm:
* _remove_r should still set reent->_errno
* _GLOBAL_REENT isn't threadlocal, what about __getreent()

So maybe:
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 4742c6653..9c498cd46 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1122,35 +1122,28 @@ unlink (const char *ourname)
 }
 
 extern "C" int
-_remove_r (struct _reent *, const char *ourname)
+_remove_r (struct _reent *ptr, const char *ourname)
 {
   path_conv win32_name (ourname, PC_SYM_NOFOLLOW);
 
   if (win32_name.error)
 {
-  set_errno (win32_name.error);
+  ptr->_errno = set_errno (win32_name.error);
   syscall_printf ("%R = remove(%s)",-1, ourname);
   return -1;
 }
 
-  return win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
+  int res = win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
+  if (errno!=0)
+  ptr->_errno = errno;
+  syscall_printf ("%R = remove(%s)", res, ourname);
+  return res;
 }
 
 extern "C" int
 remove (const char *ourname)
 {
-  path_conv win32_name (ourname, PC_SYM_NOFOLLOW);
-
-  if (win32_name.error)
-{
-  set_errno (win32_name.error);
-  syscall_printf ("-1 = remove (%s)", ourname);
-  return -1;
-}
-
-  int res = win32_name.isdir () ? rmdir (ourname) : unlink (ourname);
-  syscall_printf ("%R = remove(%s)", res, ourname);
-  return res;
+  return _remove_r (__getreent (), ourname);
 }
 
 extern "C" pid_t


Ben...

Re: [PATCH 02/11] syscalls.cc: Deduplicate _remove_r

[Ben]

On 18-01-2021 11:56, Corinna Vinschen via Cygwin-patches wrote:
> Hmm, you're adding another function call to the call stack.  Doesn't
> that slow down _remove_r rather than speeding it up?  Ok, this function
> is called from _tmpfile_r/_tmpfile64_r only, so dedup may trump speed
> here...
> 
> What's your stance?
> 
While I could do without:
In an earlier version I had changed remove and missed remove_r.

So, this commit is more about de-duplication rather than speed.


Ben...

Re: [PATCH 01/11] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE first

[Ben]

On 18-01-2021 11:45, Corinna Vinschen via Cygwin-patches wrote:
> Rather than calling NtSetInformationFile here again, we should rather
> just skip the transaction stuff on 1809 and later.  I'd suggest adding
> another wincap flag like, say, "has_posix_ro_override", being true
> for 1809 and later.  Then we can skip the transaction handling if
> wincap.has_posix_ro_override () and just add the
> FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE flag to fdie.Flags, if
> it's available.

Hmmm, I'm not sure if I follow you: This extra NtSetInformationFile is not
related to the transaction stuff?

Also I have seen NtSetInformationFile fail with STATUS_INVALID_PARAMETER.
So a retry without FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE is valid here.

I have thought about adding 
wincap.has_posix_unlink_semantics_with_ignore_readonly
but it is equal to wincap.has_posix_rename_semantics so I didn't bother adding 
it.

Ben...

Re: [PATCH 07/11] syscalls.cc: Implement non-path_conv dependent _unlink_nt

[Ben]

Hi,

After reiterating over my patches, I see this must come after
implementing the 'poor mans cache' commit.

I will reorder in a new patch-set.


Sorry about that.

Ben...

On 15-01-2021 14:45, Ben Wijen wrote:
> Implement _unlink_nt: wich does not depend on patch_conv
> ---
>  winsup/cygwin/fhandler_disk_file.cc |   4 +-
>  winsup/cygwin/forkable.cc   |   4 +-
>  winsup/cygwin/syscalls.cc   | 239 ++--
>  3 files changed, 228 insertions(+), 19 deletions(-)
> 

[PATCH 11/11] dir.cc: Try unlink_nt first

[Ben Wijen]

Speedup deletion of directories.
---
 winsup/cygwin/dir.cc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index f912a9e47..2e7da3638 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -22,6 +22,8 @@ details. */
 #include "cygtls.h"
 #include "tls_pbuf.h"
 
+extern NTSTATUS unlink_nt (const char *ourname, ULONG eflags);
+
 extern "C" int
 dirfd (DIR *dir)
 {
@@ -398,6 +400,10 @@ rmdir (const char *dir)
  if (msdos && p == dir + 1 && isdrive (dir))
p[1] = '\\';
}
+  if(NT_SUCCESS(unlink_nt (dir, FILE_DIRECTORY_FILE))) {
+res = 0;
+__leave;
+  }
   if (!(fh = build_fh_name (dir, PC_SYM_NOFOLLOW)))
__leave;   /* errno already set */;
 
-- 
2.29.2

[PATCH 08/11] path.cc: Allow to skip filesystem checks

[Ben Wijen]

When file attributes are of no concern,
there is no point to query them.
---
 winsup/cygwin/path.cc | 3 +++
 winsup/cygwin/path.h  | 1 +
 2 files changed, 4 insertions(+)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index abd3687df..f00707e86 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -931,7 +931,10 @@ path_conv::check (const char *src, unsigned opt,
 
 is_fs_via_procsys:
 
+   if (!(opt & PC_SKIP_SYM_CHECK))
+   {
  symlen = sym.check (full_path, suff, fs, conv_handle);
+   }
 
 is_virtual_symlink:
 
diff --git a/winsup/cygwin/path.h b/winsup/cygwin/path.h
index 62bd5ddd5..56855e1c9 100644
--- a/winsup/cygwin/path.h
+++ b/winsup/cygwin/path.h
@@ -59,6 +59,7 @@ enum pathconv_arg
   PC_KEEP_HANDLE= _BIT (12),   /* keep handle for later stat calls */
   PC_NO_ACCESS_CHECK= _BIT (13),   /* helper flag for error check */
   PC_SYM_NOFOLLOW_DIR   = _BIT (14),   /* don't follow a trailing slash */
+  PC_SKIP_SYM_CHECK = _BIT (15),   /* skip symlink_info::check */
   PC_DONT_USE   = _BIT (31)/* conversion to signed happens. */
 };
 
-- 
2.29.2

[PATCH 09/11] mount.cc: Implement poor-man's cache

[Ben Wijen]

Try to avoid NtQueryVolumeInformationFile.
---
 winsup/cygwin/mount.cc | 78 --
 winsup/cygwin/mount.h  |  2 +-
 winsup/cygwin/path.cc  |  2 +-
 winsup/cygwin/path.h   |  1 +
 4 files changed, 56 insertions(+), 27 deletions(-)

diff --git a/winsup/cygwin/mount.cc b/winsup/cygwin/mount.cc
index e0349815d..1d2b3a61a 100644
--- a/winsup/cygwin/mount.cc
+++ b/winsup/cygwin/mount.cc
@@ -82,6 +82,32 @@ win32_device_name (const char *src_path, char *win32_path, 
device& dev)
   return true;
 }
 
+static uint32_t
+hash_prefix (const PUNICODE_STRING upath)
+{
+  UNICODE_STRING prefix;
+  WCHAR *p;
+
+  if (upath->Buffer[5] == L':' && upath->Buffer[6] == L'\\')
+p = upath->Buffer + 6;
+  else
+{
+  /* We're expecting an UNC path.  Move p to the backslash after
+   "\??\UNC\server\share" or the trailing NUL. */
+  p = upath->Buffer + 7; /* Skip "\??\UNC" */
+  int bs_cnt = 0;
+
+  while (*++p)
+if (*p == L'\\')
+  if (++bs_cnt > 1)
+break;
+}
+  RtlInitCountedUnicodeString (, upath->Buffer,
+   (p - upath->Buffer) * sizeof(WCHAR));
+
+  return hash_path_name ((ino_t) 0, );
+}
+
 /* Beginning with Samba 3.0.28a, Samba allows to get version information using
the ExtendedInfo member returned by a FileFsObjectIdInformation request.
We just store the samba_version information for now.  Older versions than
@@ -106,14 +132,16 @@ class fs_info_cache
   struct {
 fs_info fsi;
 uint32_t hash;
+uint32_t prefix_hash;
   } entry[MAX_FS_INFO_CNT];
 
   uint32_t genhash (PFILE_FS_VOLUME_INFORMATION);
 
 public:
   fs_info_cache () : count (0) { fsi_lock.init ("fsi_lock"); }
+  fs_info *search (uint32_t);
   fs_info *search (PFILE_FS_VOLUME_INFORMATION, uint32_t &);
-  void add (uint32_t, fs_info *);
+  void add (uint32_t, fs_info *, uint32_t);
 };
 
 static fs_info_cache fsi_cache;
@@ -142,22 +170,31 @@ fs_info_cache::search (PFILE_FS_VOLUME_INFORMATION pffvi, 
uint32_t )
   return [i].fsi;
   return NULL;
 }
+fs_info*
+fs_info_cache::search (uint32_t prefix_hash)
+{
+  for (uint32_t i = 0; i < count; ++i)
+if (entry[i].prefix_hash == prefix_hash)
+  return [i].fsi;
+  return NULL;
+}
 
 void
-fs_info_cache::add (uint32_t hashval, fs_info *new_fsi)
+fs_info_cache::add (uint32_t hashval, fs_info *new_fsi, uint32_t prefix_hash)
 {
   fsi_lock.acquire ();
   if (count < MAX_FS_INFO_CNT)
 {
   entry[count].fsi = *new_fsi;
   entry[count].hash = hashval;
+  entry[count].prefix_hash = prefix_hash;
   ++count;
 }
   fsi_lock.release ();
 }
 
 bool
-fs_info::update (PUNICODE_STRING upath, HANDLE in_vol)
+fs_info::update (PUNICODE_STRING upath, HANDLE in_vol, bool use_prefix_hash)
 {
   NTSTATUS status = STATUS_OBJECT_NAME_NOT_FOUND;
   HANDLE vol;
@@ -178,6 +215,17 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol)
   UNICODE_STRING fsname;
 
   clear ();
+
+  if (use_prefix_hash)
+{
+  fs_info *fsi = fsi_cache.search (hash_prefix (upath));
+  if (fsi)
+{
+  *this = *fsi;
+  return true;
+}
+}
+
   /* Always caseinsensitive.  We really just need access to the drive. */
   InitializeObjectAttributes (, upath, OBJ_CASE_INSENSITIVE, NULL, NULL);
   if (in_vol)
@@ -233,27 +281,7 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol)
 a unique per-drive/share hash. */
   if (ffvi_buf.ffvi.VolumeSerialNumber == 0)
{
- UNICODE_STRING path_prefix;
- WCHAR *p;
-
- if (upath->Buffer[5] == L':' && upath->Buffer[6] == L'\\')
-   p = upath->Buffer + 6;
- else
-   {
- /* We're expecting an UNC path.  Move p to the backslash after
-"\??\UNC\server\share" or the trailing NUL. */
- p = upath->Buffer + 7;  /* Skip "\??\UNC" */
- int bs_cnt = 0;
-
- while (*++p)
-   if (*p == L'\\')
-   if (++bs_cnt > 1)
- break;
-   }
- RtlInitCountedUnicodeString (_prefix, upath->Buffer,
-  (p - upath->Buffer) * sizeof (WCHAR));
- ffvi_buf.ffvi.VolumeSerialNumber = hash_path_name ((ino_t) 0,
-_prefix);
+ ffvi_buf.ffvi.VolumeSerialNumber = hash_prefix(upath);
}
   fs_info *fsi = fsi_cache.search (_buf.ffvi, hash);
   if (fsi)
@@ -460,7 +488,7 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol)
 
   if (!in_vol)
 NtClose (vol);
-  fsi_cache.add (hash, this);
+  fsi_cache.add (hash, this, hash_prefix (upath));
   return true;
 }
 
diff --git a/winsup/cygwin/mount.h b/winsup/cygwin/mount.h
index 122a679a8..86b72fb4c 100644
--- a/winsup/cygwin/mount.h
+++ b/winsup/cygwin/mount.h
@@ -124,7 +124,7 @@ class fs_info
 
   const char *fsname () const { return fsn[0] ? fsn : "unknown"; }
 
-  bool __reg3 update 

[PATCH 10/11] syscalls.cc: Expose shallow-pathconv unlink_nt

[Ben Wijen]

Not having to query file information improves unlink speed.
---
 winsup/cygwin/syscalls.cc | 68 ---
 1 file changed, 42 insertions(+), 26 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 79e4a4422..8aecdf453 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1305,6 +1305,18 @@ _unlink_ntpc_ (path_conv& pc, bool shareable)
   return status;
 }
 
+NTSTATUS
+unlink_nt (const char *ourname, ULONG eflags)
+{
+  path_conv pc (ourname, PC_SYM_NOFOLLOW | PC_FS_USE_PREFIX_HASH | 
PC_SKIP_SYM_CHECK, NULL);
+  dev_t devn = pc.get_device ();
+  if (pc.error || isproc_dev (devn))
+return STATUS_CANNOT_DELETE;
+
+  PUNICODE_STRING ntpath = pc.get_nt_native_path ();
+  return _unlink_nt (ntpath, eflags, 0);
+}
+
 NTSTATUS
 unlink_ntpc (path_conv )
 {
@@ -1322,37 +1334,41 @@ unlink (const char *ourname)
 {
   int res = -1;
   dev_t devn;
-  NTSTATUS status;
+  NTSTATUS status = unlink_nt (ourname, FILE_NON_DIRECTORY_FILE);
 
-  path_conv win32_name (ourname, PC_SYM_NOFOLLOW, stat_suffixes);
+  if (!NT_SUCCESS (status))
+  {
+path_conv win32_name (ourname, PC_SYM_NOFOLLOW, stat_suffixes);
 
-  if (win32_name.error)
-{
-  set_errno (win32_name.error);
-  goto done;
-}
+if (win32_name.error)
+  {
+set_errno (win32_name.error);
+goto done;
+  }
 
-  devn = win32_name.get_device ();
-  if (isproc_dev (devn))
-{
-  set_errno (EROFS);
-  goto done;
-}
+devn = win32_name.get_device ();
+if (isproc_dev (devn))
+  {
+set_errno (EROFS);
+goto done;
+  }
 
-  if (!win32_name.exists ())
-{
-  debug_printf ("unlinking a nonexistent file");
-  set_errno (ENOENT);
-  goto done;
-}
-  else if (win32_name.isdir ())
-{
-  debug_printf ("unlinking a directory");
-  set_errno (EISDIR);
-  goto done;
-}
+if (!win32_name.exists ())
+  {
+debug_printf ("unlinking a nonexistent file");
+set_errno (ENOENT);
+goto done;
+  }
+else if (win32_name.isdir ())
+  {
+debug_printf ("unlinking a directory");
+set_errno (EISDIR);
+goto done;
+  }
+
+status = unlink_ntpc (win32_name);
+  }
 
-  status = unlink_ntpc (win32_name);
   if (NT_SUCCESS (status))
 res = 0;
   else
-- 
2.29.2

[PATCH 06/11] cxx.cc: Fix dynamic initialization for static local variables

[Ben Wijen]

The old implementation for __cxa_guard_acquire did not return 1,
therefore dynamic initialization was never performed.

If concurrent-safe dynamic initialisation is ever needed, CXX ABI
must be followed when re-implementing __cxa_guard_acquire (et al.)
---
 winsup/cygwin/Makefile.in |  2 +-
 winsup/cygwin/cxx.cc  | 10 --
 2 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in
index a840f2b83..73d9b37fd 100644
--- a/winsup/cygwin/Makefile.in
+++ b/winsup/cygwin/Makefile.in
@@ -69,7 +69,7 @@ COMMON_CFLAGS=-MMD ${$(*F)_CFLAGS} -Wimplicit-fallthrough=5 
-Werror -fmerge-cons
 ifeq ($(target_cpu),x86_64)
 COMMON_CFLAGS+=-mcmodel=small
 endif
-COMPILE.cc+=${COMMON_CFLAGS} # -std=gnu++14
+COMPILE.cc+=${COMMON_CFLAGS} -fno-threadsafe-statics # -std=gnu++14
 COMPILE.c+=${COMMON_CFLAGS}
 
 AR:=@AR@
diff --git a/winsup/cygwin/cxx.cc b/winsup/cygwin/cxx.cc
index be3268549..b69524aca 100644
--- a/winsup/cygwin/cxx.cc
+++ b/winsup/cygwin/cxx.cc
@@ -83,16 +83,6 @@ __cxa_pure_virtual (void)
   api_fatal ("pure virtual method called");
 }
 
-extern "C" void
-__cxa_guard_acquire ()
-{
-}
-
-extern "C" void
-__cxa_guard_release ()
-{
-}
-
 /* These routines are made available as last-resort fallbacks
for the application.  Should not be used in practice; the
entries in this struct get overwritten by each DLL as it
-- 
2.29.2

[PATCH 07/11] syscalls.cc: Implement non-path_conv dependent _unlink_nt

[Ben Wijen]

Implement _unlink_nt: wich does not depend on patch_conv
---
 winsup/cygwin/fhandler_disk_file.cc |   4 +-
 winsup/cygwin/forkable.cc   |   4 +-
 winsup/cygwin/syscalls.cc   | 239 ++--
 3 files changed, 228 insertions(+), 19 deletions(-)

diff --git a/winsup/cygwin/fhandler_disk_file.cc 
b/winsup/cygwin/fhandler_disk_file.cc
index 07f9c513a..fe04f832b 100644
--- a/winsup/cygwin/fhandler_disk_file.cc
+++ b/winsup/cygwin/fhandler_disk_file.cc
@@ -1837,7 +1837,7 @@ fhandler_disk_file::mkdir (mode_t mode)
 int
 fhandler_disk_file::rmdir ()
 {
-  extern NTSTATUS unlink_nt (path_conv );
+  extern NTSTATUS unlink_ntpc (path_conv );
 
   if (!pc.isdir ())
 {
@@ -1850,7 +1850,7 @@ fhandler_disk_file::rmdir ()
   return -1;
 }
 
-  NTSTATUS status = unlink_nt (pc);
+  NTSTATUS status = unlink_ntpc (pc);
 
   if (!NT_SUCCESS (status))
 {
diff --git a/winsup/cygwin/forkable.cc b/winsup/cygwin/forkable.cc
index 350a95c3e..bd7421bf5 100644
--- a/winsup/cygwin/forkable.cc
+++ b/winsup/cygwin/forkable.cc
@@ -29,7 +29,7 @@ details. */
 
 /* Allow concurrent processes to use the same dll or exe
  * via their hardlink while we delete our hardlink. */
-extern NTSTATUS unlink_nt_shareable (path_conv );
+extern NTSTATUS unlink_ntpc_shareable (path_conv );
 
 #define MUTEXSEP L"@"
 #define PATHSEP L"\\"
@@ -132,7 +132,7 @@ rmdirs (WCHAR ntmaxpathbuf[NT_MAX_PATH])
  RtlInitUnicodeString (, ntmaxpathbuf);
 
  path_conv pc ();
- unlink_nt_shareable (pc); /* move to bin */
+ unlink_ntpc_shareable (pc); /* move to bin */
}
 
  if (!pfdi->NextEntryOffset)
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index f86a93825..79e4a4422 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -491,7 +491,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   break;
 case STATUS_DIRECTORY_NOT_EMPTY:
   /* Uh oh!  This was supposed to be avoided by the check_dir_not_empty
-test in unlink_nt, but given that the test isn't atomic, this *can*
+test in unlink_ntpc, but given that the test isn't atomic, this *can*
 happen.  Try to move the dir back ASAP. */
   pfri->RootDirectory = NULL;
   pfri->FileNameLength = pc.get_nt_native_path ()->Length;
@@ -501,7 +501,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   if (NT_SUCCESS (NtSetInformationFile (fh, , pfri, frisiz,
FileRenameInformation)))
{
- /* Give notice to unlink_nt and leave immediately.  This avoids
+ /* Give notice to unlink_ntpc and leave immediately.  This avoids
 closing the handle, which might still be used if called from
 the rm -r workaround code. */
  bin_stat = dir_not_empty;
@@ -545,7 +545,7 @@ try_to_bin (path_conv , HANDLE , ACCESS_MASK access, 
ULONG flags)
   if ((access & FILE_WRITE_ATTRIBUTES) && NT_SUCCESS (status) && !pc.isdir ())
 NtSetAttributesFile (fh, pc.file_attributes ());
   NtClose (fh);
-  fh = NULL; /* So unlink_nt doesn't close the handle twice. */
+  fh = NULL; /* So unlink_ntpc doesn't close the handle twice. */
   /* On success or when trying to unlink a directory we just return here.
  The below code only works for files.  It also fails on NFS. */
   if (NT_SUCCESS (status) || pc.isdir () || pc.fs_is_nfs ())
@@ -671,7 +671,187 @@ check_dir_not_empty (HANDLE dir, path_conv )
 }
 
 static NTSTATUS
-_unlink_nt (path_conv , bool shareable)
+_unlink_nt (PUNICODE_STRING ntpath, ULONG eflags, ULONG oattr)
+{
+  //Available as of Redstone 1 (Win10_17_09)
+  static bool has_posix_unlink_semantics =
+  wincap.has_posix_unlink_semantics ();
+  //Available as of Redstone 5 (Win10_18_09) (As were POSIX rename semantics)
+  static bool has_posix_unlink_semantics_with_ignore_readonly =
+  wincap.has_posix_rename_semantics ();
+
+  HANDLE fh;
+  ACCESS_MASK access = DELETE;
+  OBJECT_ATTRIBUTES attr;
+  IO_STATUS_BLOCK io;
+  ULONG flags = FILE_OPEN_REPARSE_POINT | FILE_OPEN_FOR_BACKUP_INTENT
+  | FILE_DELETE_ON_CLOSE | eflags;
+  NTSTATUS fstatus, istatus = STATUS_SUCCESS;
+
+  syscall_printf("Trying to delete %S, isdir = %d", ntpath,
+ eflags == FILE_DIRECTORY_FILE);
+
+  InitializeObjectAttributes(, ntpath, oattr, NULL, NULL);
+
+  //FILE_DELETE_ON_CLOSE icw FILE_DIRECTORY_FILE only works when directory is 
empty
+  //-> We must assume directory not empty, therefore only do this for regular 
files.
+  if (eflags & FILE_NON_DIRECTORY_FILE)
+{
+  //Step 1
+  //If the file is not 'in use' and not 'readonly', this should just work.
+  fstatus = NtOpenFile (, access, , , FILE_SHARE_DELETE, flags);
+  debug_printf("NtOpenFile %S: %y", ntpath, fstatus);
+}
+
+  if (!(eflags & FILE_NON_DIRECTORY_FILE) || // Workaround for the 
non-empty-dir issue
+  fstatus == 

[PATCH 04/11] syscalls.cc: Use EISDIR

[Ben Wijen]

This is the non-POSIX value returned by Linux since 2.1.132.
---
 winsup/cygwin/syscalls.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 227d1a911..043ccdb99 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -1118,7 +1118,7 @@ unlink (const char *ourname)
   else if (win32_name.isdir ())
 {
   debug_printf ("unlinking a directory");
-  set_errno (EPERM);
+  set_errno (EISDIR);
   goto done;
 }
 
-- 
2.29.2

[PATCH 03/11] syscalls.cc: Fix num_links

[Ben Wijen]

NtQueryInformationFile on fh_ro needs FILE_READ_ATTRIBUTES
to succeed.
---
 winsup/cygwin/syscalls.cc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 0e89b4f44..227d1a911 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -767,8 +767,9 @@ _unlink_nt (path_conv , bool shareable)
   if ((pc.fs_flags () & FILE_SUPPORTS_TRANSACTIONS))
start_transaction (old_trans, trans);
 retry_open:
-  status = NtOpenFile (_ro, FILE_WRITE_ATTRIBUTES, , ,
-  FILE_SHARE_VALID_FLAGS, flags);
+  status = NtOpenFile (_ro,
+   FILE_READ_ATTRIBUTES | FILE_WRITE_ATTRIBUTES,
+   , , FILE_SHARE_VALID_FLAGS, flags);
   if (NT_SUCCESS (status))
{
  debug_printf ("Opening %S for removing R/O succeeded",
-- 
2.29.2

[PATCH 01/11] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE first

[Ben Wijen]

---
 winsup/cygwin/ntdll.h |  3 ++-
 winsup/cygwin/syscalls.cc | 20 
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/winsup/cygwin/ntdll.h b/winsup/cygwin/ntdll.h
index d4f6aaf45..7eee383dd 100644
--- a/winsup/cygwin/ntdll.h
+++ b/winsup/cygwin/ntdll.h
@@ -497,7 +497,8 @@ enum {
   FILE_DISPOSITION_DELETE  = 0x01,
   FILE_DISPOSITION_POSIX_SEMANTICS = 0x02,
   FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK   = 0x04,
-  FILE_DISPOSITION_ON_CLOSE= 0x08
+  FILE_DISPOSITION_ON_CLOSE= 0x08,
+  FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE   = 0x10,
 };
 
 enum
diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
index 525efecf3..ce4e9c65c 100644
--- a/winsup/cygwin/syscalls.cc
+++ b/winsup/cygwin/syscalls.cc
@@ -709,11 +709,23 @@ _unlink_nt (path_conv , bool shareable)
   flags);
   if (!NT_SUCCESS (status))
goto out;
-  /* Why didn't the devs add a FILE_DELETE_IGNORE_READONLY_ATTRIBUTE
-flag just like they did with FILE_LINK_IGNORE_READONLY_ATTRIBUTE
-and FILE_LINK_IGNORE_READONLY_ATTRIBUTE???
+  /* Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE first
+ it was added with Redstone 5 (Win10 18_09) (as were POSIX rename 
semantics)
+ If it fails: fall-back to usual trickery */
+  if (wincap.has_posix_rename_semantics ())
+{
+  fdie.Flags = FILE_DISPOSITION_DELETE | 
FILE_DISPOSITION_POSIX_SEMANTICS;
+  fdie.Flags|= FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE;
+  status = NtSetInformationFile (fh, , , sizeof fdie,
+ FileDispositionInformationEx);
+  if (NT_SUCCESS (status))
+{
+  NtClose (fh);
+  goto out;
+}
+}
 
- POSIX unlink semantics are nice, but they still fail if the file
+  /* POSIX unlink semantics are nice, but they still fail if the file
 has the R/O attribute set.  Removing the file is very much a safe
 bet afterwards, so, no transaction. */
   if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
-- 
2.29.2

Re:

[Ben Kamen]

On 12/9/20 6:15 AM, chaparay01--- via Cygwin wrote:

Who the fuck are you !   You been writing my husband
--


HAHAHAHA... Oh yes... we've been sending him the acronym list and telling him 
all about posix coding and shell scripting!!

THE HORRORS!

LoL...

 -Ben


--
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: [ITP] xxhash 0.7.4-1

[Ben RUBSON]

> On 3 Aug 2020, at 18:08, Marco Atzeri via Cygwin-apps 
>  wrote:
> 
> On 03.08.2020 07:58, Marco Atzeri wrote:
>> On 14.07.2020 21:51, Doug Henderson via Cygwin-apps wrote:
>>> On Tue, 14 Jul 2020 at 10:29, ASSI <> wrote:
>>>> 
> 
>> looks good, but I have no time for adding the package to
>> cygwin-pkg-maint
>> so if no one do it before, I will add it this evening (CET)
>> Regards
>> Marco
> 
> Doug,
> you can upload

Hi,

Did you somehow manage to go further ? :)

Thank you again guys !

Best regards,

Ben

Re: [ITP] xxhash 0.7.4-1

[Ben RUBSON]

> On 14 Jul 2020, at 21:51, Doug Henderson via Cygwin-apps 
>  wrote:
> 
> On Tue, 14 Jul 2020 at 10:29, ASSI <> wrote:
>> 
>> ASSI writes:
>>> By patching the Makefile, just like you need to do for all the other
>>> stuff from the same author.  You can have a look at the zstd packages.
>> 
>> Come to think of it, xxhash is already part of zstd.  Can't you just
>> link to that?
>> 
>> 
>> Regards,
>> Achim.
> 
> I have patched the Makefile as suggested. The newest version of the
> dist files as located at
> 
> https://github.com/djhenderson/Temp/raw/master/xxhash.zip
> 
> (...)
> 
> Any way, I would like some critical feedback on the dist packaging.

Hi,

Not sure about the whole integration process, but any news perhaps regarding 
this package release ?

Thank you very much,

Kind regards,

Ben

Re: [ITP] xxhash 0.7.4-1

[Ben RUBSON]

> On 14 Jul 2020, at 21:51, Doug Henderson via Cygwin-apps 
>  wrote:
> 
> On Tue, 14 Jul 2020 at 10:29, ASSI <> wrote:
>> 
>> ASSI writes:
>>> By patching the Makefile, just like you need to do for all the other
>>> stuff from the same author.  You can have a look at the zstd packages.
>> 
>> Come to think of it, xxhash is already part of zstd.  Can't you just
>> link to that?
>> 
>> 
>> Regards,
>> Achim.
> 
> I have patched the Makefile as suggested. The newest version of the
> dist files as located at
> 
> https://github.com/djhenderson/Temp/raw/master/xxhash.zip
> 

> (...)
> 
> Any way, I would like some critical feedback on the dist packaging.

Many thanks Doug, really nice work !
At least I successfully manage to build rsync with this package :

$ uname -s -r
CYGWIN_NT-6.1 3.1.6(0.340/5/3)

$ ./rsync --version
rsync  version 3.2.3dev  protocol version 31
(...)
Optimizations:
no SIMD, asm, openssl-crypto
Checksum list:
xxh64 (xxhash) md5 md4 none
Compress list:
zstd lz4 zlibx zlib none

Not sure about the other things to check though.

Kind regards,

Ben

rsync + xxhash packages

[Ben RUBSON]

Hi,

New rsync version (3.2.x) brings a lot of interesting new features.

It then now depends on various libraries :
- openssl
- zstd
- lz4
- xxhash

Cygwin already has the first 3 ones.
But it lacks xxhash.

Would then be nice to have a Cygwin package for xxash, so that new rsync 
version could be flawlessly built with all the new features.
https://github.com/Cyan4973/xxHash

May I then ask, could one of the maintainers have a look into packaging this 
new library please ?

And when updating the rsync package (Jari Aalto ?), please properly link 
against the 4 above libraires ?

For my part, I plan to write a CI for rsync on Cygwin, as soon as xxash package 
will be available.

Thank you very much for your support,

Best regards,

Ben

Re: Using ARM GNU GCC with Cygwin

[Ben Kamen]

Well then.

This certainly turned out to be all sorts of interesting discussion. :)

I for one also can say it's nice to have a cygwin environment over DOS if I'm 
forced to a CLI on Windows.

Most of my days are spent on Linux  -- but it looks like I have some legit CLI 
time coming on Windows and cygwin was my first go-to thought for that.

It's already bad enough how many times I type 'ls -l' in DOS to get an error. 
HAhahaha.

(two thumbs up)

 -Ben
--
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: Using ARM GNU GCC with Cygwin

[Ben]

Thanks for everyone's comments...

I ended up getting the stock arm-gcc working just find if I got rid of absolute 
paths and just worked with relatives.

I'm amused. :D

Cygwin saves me once again from working in the DOS prompt environment. :P


 -Ben


--
Ben Kamen - O.D.T., S.P.
--
eMail: ben AT benjammin DOT net   http://www.benjammin.net
Fortune says:
Hailing frequencies open, Captain.
-  -
NOTICE: All legal disclaimers sent to benjammin.net/benkamen.net
or any of it's affiliated domains are rendered null and void on
receipt of communications and will be handled/considered as such.

--
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: Using ARM GNU GCC with Cygwin

[Ben]

On 4/4/20 1:58 PM, Åke Rehnman via Cygwin wrote:



I do cross compiling all the time in cygwin and the reason is of course to not 
have to deal with windows paths and what not plus you have access to all the 
build tools like make binutils grep sed autotools.



Are you doing any arm compilation?  I'd be amused to get this to work on 
Windows (under Cygwin).

Cheers,

 -Ben

--
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: Using ARM GNU GCC with Cygwin

[Ben]

On 4/4/20 9:32 AM, Kaz Kylheku wrote:

On 2020-04-04 02:00, Ben wrote:

Is there something else I'm missing?


That by cross-compiling for your targets on Cygwin instead of a real POSIX OS, 
you will something like double your compile times, if not more.

Why would you involve Cygwin in a development activity whose target isn't POSIX 
on Windows.


The make files do differentiate between windows and posix.

And the compiler is supplied by the GCC folks for Windows as well as Linux/Unix.

I just thought I'd try it out. It's so close to working, I thought that'd be 
neat.

My main linux  system is scheduled for a major upgrade (CentOS 6 to 8). So i 
thought I'd see how well gcc for arm on windows played with Cygwin.


 Cheers,

 -Ben
--
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: Using ARM GNU GCC with Cygwin

[Ben]

On 4/4/20 5:23 AM, Eliot Moss wrote:

On 4/4/2020 5:00 AM, Ben wrote:

> I've been playing with ARM GNU GCC and some examples from nordic 
semiconductor for some of their
> demo boards (The Thingy)

Sounds as if that is a Windows program, not a Cygwin or Linux program.

> The make file that comes with the project includes source files using the 
(abspath ../main.c) (as
> one example) which GCC really seems to hate.

> The output from GCC is the full path (/home/bkamen/workspace-nordic/.) 
right down to the file
> and gcc tells me it can't find the file.

If your gcc is a Windows gcc then it wants a Windows path.

> if I change the mail file to use a relative path, gcc can find that... but 
ultimately I'm trying to
> understand the issue than just patch around it.

This goes along with my theory.

> I'm using the arm-gcc from the developer.arm.com website.
>
> Is there something else I'm missing? What files can I offer (like the 
makefile) that can help
> determine the issue?

You can fix the Makefile to pass Windows paths.  The cygpath tool and make's
$(shell ...) command might be useful.

But I also wonder if maybe the mingw environment is more suited to this work,
or finding a Windows version of make.


Yea, that's what I figured.

I thought I would try it and see how it worked out -- and it was so close... 
that I figured it'd be worth asking if anyone had worked with doing something 
similar.

Cheers,

 -Ben
--
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

Using ARM GNU GCC with Cygwin

[Ben]

Hey all,

 I've never used Cygwin much in the past for compiling let alone 
cross-compiling to another arch.

I've been playing with ARM GNU GCC and some examples from nordic semiconductor 
for some of their demo boards (The Thingy)

The make file that comes with the project includes source files using the 
(abspath ../main.c) (as one example) which GCC really seems to hate.

The output from GCC is the full path (/home/bkamen/workspace-nordic/.) 
right down to the file and gcc tells me it can't find the file.

if I change the mail file to use a relative path, gcc can find that... but 
ultimately I'm trying to understand the issue than just patch around it.

I'm using the arm-gcc from the developer.arm.com website.

Is there something else I'm missing? What files can I offer (like the makefile) 
that can help determine the issue?

Thanks,

 -Ben


--
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: [PATCH] mkdir: always check-for-existence

[Ben]

Hi Corinna,

Please see the attachment for my patch.
My MUA indeed replaced the tabs with spaces.

I did notice that the indentation was mixed tabs and spaces,
but as stated on the website I have kept the surrounding indentation.


Ben...

On 04-06-2019 09:41, Corinna Vinschen wrote:

Hi Ben,

On Jun  3 22:07, Ben wrote:

When creating a directory which already exists, NtCreateFile will correctly
return 'STATUS_OBJECT_NAME_COLLISION'.

However when creating a directory and all its parents a normal use would
be to start with mkdir(‘/cygdrive/c’) which translates to ‘C:\’ for which
it'll
instead return ‘STATUS_ACCESS_DENIED’.

So we better check for existence prior to calling NtCreateFile.
---
  winsup/cygwin/dir.cc | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index f43eae461..b757851d5 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -331,8 +331,10 @@ mkdir (const char *dir, mode_t mode)
        debug_printf ("got %d error from build_fh_name", fh->error ());
        set_errno (fh->error ());
      }
+  else if (fh->exists ())
+    set_errno (EEXIST);
    else if (has_dot_last_component (dir, true))
-    set_errno (fh->exists () ? EEXIST : ENOENT);
+    set_errno (ENOENT);
    else if (!fh->mkdir (mode))
      res = 0;
    delete fh;

--
2.21.0

I was just trying to apply your patch but it fails to apply cleanly.
Can you please check your indentation?  The `else' lines are indented
more than the lines in between and TABs are missing.

Maybe your MUA breaks the output?  If all else fails, you could attach
your patch as plain/text attachement to your mail, usually that's left
alone by the MUA.


Thanks,
Corinna



>From 190b5bc9497a1332ce53afd831debe1ac3e53ffb Mon Sep 17 00:00:00 2001
From: Ben Wijen 
Date: Mon, 3 Jun 2019 20:15:50 +0200
Subject: [PATCH] mkdir: always check-for-existence
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When using NtCreateFile when creating a directory that already exists,
it will correctly return 'STATUS_OBJECT_NAME_COLLISION'.

However using this function to create a directory (and all its parents)
a normal use would be to start with mkdir(‘/cygdrive/c’) which translates
to ‘C:\’ for which it'll instead return ‘STATUS_ACCESS_DENIED’.
---
 winsup/cygwin/dir.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index f43eae461..b757851d5 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -331,8 +331,10 @@ mkdir (const char *dir, mode_t mode)
 	  debug_printf ("got %d error from build_fh_name", fh->error ());
 	  set_errno (fh->error ());
 	}
+  else if (fh->exists ())
+	set_errno (EEXIST);
   else if (has_dot_last_component (dir, true))
-	set_errno (fh->exists () ? EEXIST : ENOENT);
+	set_errno (ENOENT);
   else if (!fh->mkdir (mode))
 	res = 0;
   delete fh;
-- 
2.21.0

Re: [PATCH] mkdir: always check-for-existence

[Ben]

When creating a directory which already exists, NtCreateFile will correctly
return 'STATUS_OBJECT_NAME_COLLISION'.

However when creating a directory and all its parents a normal use would
be to start with mkdir(‘/cygdrive/c’) which translates to ‘C:\’ for 
which it'll

instead return ‘STATUS_ACCESS_DENIED’.

So we better check for existence prior to calling NtCreateFile.
---
 winsup/cygwin/dir.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index f43eae461..b757851d5 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -331,8 +331,10 @@ mkdir (const char *dir, mode_t mode)
       debug_printf ("got %d error from build_fh_name", fh->error ());
       set_errno (fh->error ());
     }
+  else if (fh->exists ())
+    set_errno (EEXIST);
   else if (has_dot_last_component (dir, true))
-    set_errno (fh->exists () ? EEXIST : ENOENT);
+    set_errno (ENOENT);
   else if (!fh->mkdir (mode))
     res = 0;
   delete fh;

--
2.21.0

[PATCH] mkdir: alway check-for-existence

[Ben]

When using either CreateDirectory or NtCreateFile when creating a directory
that already exists, these functions return: ERROR_ALREADY_EXISTS

However when using these function to create a directory (and all its 
parents)

a normal use would be to start with mkdir(‘/c’) which translates to ‘C:\’
for which both of these functions return ‘ERROR_ACCESS_DENIED’

We could call NtCreateFile with 'FILE_OPEN_IF' instead of 'FILE_CREATE' but
since that's an internal function we better always check for existence
ourselves.

Signed-off-by: Ben Wijen 
---
 winsup/cygwin/dir.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/dir.cc b/winsup/cygwin/dir.cc
index f43eae461..b757851d5 100644
--- a/winsup/cygwin/dir.cc
+++ b/winsup/cygwin/dir.cc
@@ -331,8 +331,10 @@ mkdir (const char *dir, mode_t mode)
       debug_printf ("got %d error from build_fh_name", fh->error ());
       set_errno (fh->error ());
     }
+  else if (fh->exists ())
+    set_errno (EEXIST);
   else if (has_dot_last_component (dir, true))
-    set_errno (fh->exists () ? EEXIST : ENOENT);
+    set_errno (ENOENT);
   else if (!fh->mkdir (mode))
     res = 0;
   delete fh;

--
2.21.0

One problem: Couldn't compute FAST_CWD pointer

[Yueting Ben]

Hello Cygwin,

I am the employee in BCS, I am trying the makefile provided by Vector,
I meet one problem maybe can be solved by you, because the warning comments 
show that can ask help from your email;

Can you give me some guidance for this situation, I will see the response below 
when I run the m.bat for makefile,
Thankyou very much

0 [main] sh 7780 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.  
Please report this problem to
the public mailing list cygwin@cygwin.com
  0 [main] sh 8884 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] sh 3832 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  0 [main] sh 2932 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] sh 240 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] sh 1952 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] sh 12488 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] sh 7940 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  0 [main] sh 13384 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] sh 5388 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  0 [main] sh 13760 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] sh 9060 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  1 [main] sh 5784 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
  0 [main] sh 6992 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com

Best Regards
Yueting Ben


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Order Request

[Ben Jackson]

Hello Sales,
My name is Ben Jackson and i would like to know if you carry  in stock Fork 
Carriage for sale. Please contact me back with the models and pricing for the 
Fork Carriage.Thank you and will wait to hear from you soon...

 
Best Regards
Ben Jackson


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Audit Executives

[Ben Kamen]

On 03/07/2018 02:02 PM, Maria Sadie wrote:
> Did you get a chance to review my previous email? Let me know if we can 
> schedule a call to discuss further.
>
> Look forward to hearing back
>
> Regards,
>
> Maria
>

Makes you wonder if they really get back all the list emails to their inbox.

 -Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: OPT OUT

[Ben Kamen]

On 02/28/2018 12:50 AM, Wayne Barron wrote:
> To funny.
>


Sometimes I wish we could take away some adults internet access.

You know -- before they hurt themselves with it.

;)

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Searching full, portable Cygwin package for windows and NOT just the installer

[Ben via cygwin]

When I go to web page

http://cygwin.com/

then I can download CygWin from there (currently the file "setup-x86_64.exe").

Unfortunately this file is just an installer which retrieves in turn several 
other files from Internet and remote servers.

Since I have no overview what is downloaded from which server I distrust such 
installers in general.

I prefer full packages which contains everything needed and can be inspected in 
advance (e.g. by virus scanners) before
actual installation.

99,9% of all software is offered in such a way.

Why use Cygwin such a fishy distribution way?

Is there really no full package to download?

Thank you
Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

How to start Cygwin from outside Cygwin and pass a command to execute?

[Ben via cygwin]

Assume my CgyWin (on a windows 7) is currently NOT started.

Assume I want to call from Windows my CgyWin and pass a command to execute.

Afterwards CygWin should automatically be closed again.

How can I achieve this?

Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: mutt no longer sending mail

[Ben Altman]

On Thu, Dec 14, 2017 at 2:36 AM, Ben Altman <ben...@gmail.com> wrote:
> I accidentally removed parts of my cygwin installation. I reinstalled
> it with mutt, sendmail and ssmtp. I ran ssmtp-config and set it up as
> before with some minor modifications afterwards to
> /etc/ssmtp/ssmtp.conf. I also compared it to another machine I have
> and the files were basically the same. Despite this, when I do a basic
> test that used to work, it now gives me an error:
> Error sending message, child exited 127 (Exec error.).
> Could not send the message.
>
> I do have another machine where it is working and an installation of
> babun on the same machine as the one where it is not working that does
> have mutt working but I would like to get it working with cygwin on
> the machine I messed up. I googled around without success and was
> wondering if anyone could make some suggestions that would help me in
> this situation?

I should also mention that the PC has Windows 7 and it is the 32 bit
version of cygwin.
Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

mutt no longer sending mail

[Ben Altman]

I accidentally removed parts of my cygwin installation. I reinstalled
it with mutt, sendmail and ssmtp. I ran ssmtp-config and set it up as
before with some minor modifications afterwards to
/etc/ssmtp/ssmtp.conf. I also compared it to another machine I have
and the files were basically the same. Despite this, when I do a basic
test that used to work, it now gives me an error:
Error sending message, child exited 127 (Exec error.).
Could not send the message.

I do have another machine where it is working and an installation of
babun on the same machine as the one where it is not working that does
have mutt working but I would like to get it working with cygwin on
the machine I messed up. I googled around without success and was
wondering if anyone could make some suggestions that would help me in
this situation?

Thanks,
Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Building ksh93 on cygwin

[Ben Altman]

Hello,

I am trying to get ksh93 to successfully build on cygwin. My first
issue was nl_types.h being absent. I installed the catgets package to
get it and try to rebuild.

Now it is complaining about  posix_spawnattr_t:
+ cc -D_BLD_STATIC -D_BLD_ast -I.
-I/home/baltman/ast-beta/src/lib/libast -Icomp
-I/home/baltman/ast-beta/src/lib/libast/comp -Iinclude
-I/home/baltman/ast-beta/src/lib/libast/include -Istd
-I/home/baltman/ast-beta/src/lib/libast/std -D_PACKAGE_ast -c
/home/baltman/ast-beta/src/lib/libast/misc/spawnvex.c
/home/baltman/ast-beta/src/lib/libast/misc/spawnvex.c: In function 'spawnvex':
/home/baltman/ast-beta/src/lib/libast/misc/spawnvex.c:802:2: error:
unknown type name 'posix_spawnattr_t'
  posix_spawnattr_t  ax;

I asked about it on https://github.com/att/ast/issues/127 and they
said I need to look into how/where 'posix_spawnattr_t is defined under
Cygwin. Would any one here be able to help me out? I am hoping that if
I can successfully get it to compile then the next step would be to
follow the steps needed to get it included as a package for cygwin but
first things first.

Thanks.
Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

How to turn off delivery of all postings but still allow to post to this MailingList?

[Ben Stover via cygwin]

After subscribing to this mailing list I get all postings here as individual 
emails.

I prefer to read answers (and other postings) on a web page like

https://cygwin.com/ml/cygwin/2017-09/

So I need not individual emails delivery.

How can I turn it off but keep the permission to post?

Is there a way to post to this MailingList by NOT sending an email to 
cygwin@cygwin.com?

Alternatively a solution to receive answer emails to only my personal questions 
would be fine as well.

Thank you
Ben









.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

How to specify the user directory OUTSIDE of Cygwin (installation folder)?

[Ben Stover via cygwin]

By default the user folder of Cygwin (under Win7) is in a subdirectory

\home\

How can I put it into a separate directory OUTSIDE of Cygwin?

Example:

I installed Cygwin in

D:\tools\cygwin\v2\

and want to put my (resp. all) home directories into

D:\tools\cygwin\myhome\

If possible I would like to specify my new home directory not as absolute but 
as relative path.

I would prefer a customization somwhow in "Cygwin.bat" like:

set cygwinhome=..\myhome

Mind the double dots standing for "go up one level".

How can I achieve this?

Ben








.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

How to find out the current cygwin version?

[Ben Stover via cygwin]

Assume I get to another (Windows) computer where Cygwin is already installed.

How can I find out which version of Cygwin is currently installed?

Thy
Ben



.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Car Auto Wrap

[Ben Kamen]

On 07/10/2017 01:58 PM, Wayne Barron wrote:
> SPAM
>

Bloody Vikings!!

;)

 -Ben

-- 
Ben Kamen - O.D.T., S.P.
--
Email: ben AT benkamen DOT net http://www.benkamen.net
Cell:  224.619.9006http://www.linkedin.com/in/benkamen
--
NOTICE: All legal disclaimers sent to benkamen.net
or any of it's affiliated domains are rendered null and void on 
receipt of communications and will be handled/considered as such.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Redhat, Sourceware, Cygwin Web Site Outage Recovering

[Ben Kamen]

On 04/21/2017 01:30 PM, Brian Inglis wrote:
> Looks like Redhat, Sourceware, Cygwin web sites are coming 
> back up after an outage (confirmed by two isup/down sites) or 
> there have been some major network issues on the west coast

I wonder if it was west-coast...

I had issues getting to some Xilinx FPGA resources this morning....

 -Ben


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: chmod failing on user's permissions

[Ben Altman]

On 11/28/2016 7:00 PM, L. A. Walsh wrote:

Ben Altman wrote: When I get a directory listing, it shows for each

file "Unknown+User Unknown+Group" while on the desktop the same files
show my user name that I logged in with and "Domain Users" as the
group.

---
Is your laptop a member of the domain?  How do each of them
resolve User ID's?



It also shows as unknown if I create a file on the laptop.


It doesn't sound like your laptop is looking up the ID's from the same 
location as your desktop, and perhaps more likely,

it doesn't sound like your laptop is looking up ID's by checking
with the domain.

Thanks for you response. I tracked down the issue to there not being any 
/etc/group file. I did a "mkgroup > /etc/group" and the issue went away. 
I am not sure why the file wasn't there.


Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

chmod failing on user's permissions

[Ben Altman]

When I log in to my account at work I get access to a network location
accessed as a drive dedicated to me. I log in from 2 locations - my
laptop and desktop. Directory listings and chmod work as expected on
the desktop but when I try to do a chmod on the laptop, it fails for
the user's permissions, leaving them blank, but appears to work for
group and other. When I get a directory listing, it shows for each
file "Unknown+User Unknown+Group" while on the desktop the same files
show my user name that I logged in with and "Domain Users" as the
group. It also shows as unknown if I create a file on the laptop.
After googling around for an answer to the issue, I came up dry with
regards to chmod though I did find a way to change permissions using
setfacl. Does anyone know how to get chmod working the way it should?

Thanks,
Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Extreme Slowness of cygwin commands [SOLVED?]

[Ben Altman]

On 8/29/2016 3:23 PM, b...@theworld.com wrote:

On August 29, 2016 at 01:18 ben...@gmail.com (Ben Altman) wrote:
  >
  > This comes a while later but I was wrong and you were right.
  >

Glad to be of service.


As a follow up, I contacted Trusteer about the issue and did some basic 
troubleshooting and it turns out that Rapport Cerberus, one of Rapport's 
Anti-malware protection mechanisms, was the issue. Renaming all the sys 
files in 
C:\ProgramData\Trusteer\Rapport\store\exts\RapportCerberus\baseline and 
rebooting solved the problem. In the meanwhile, they said they expect 
the problem to be resolved in a future release of Rapport.


Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Extreme Slowness of cygwin commands [SOLVED?]

[Ben Altman]

On 5/27/2016 4:13 PM, Ben Altman wrote:

On 5/27/2016 3:58 PM, b...@theworld.com wrote:

As I said the slowdown was intermittant, Rapport had been running at
least a week or so before the slowdown started which didn't affect for
example cmd or power shell only cygwin that I noticed.

But when I stopped Rapport the slowdown (15+ second process
activation) disappeared instantly.

Needs more investigation but maybe this will help someone else, if I
can save just one child...


I understand and I am not disagreeing with your observations, but in 
my case, and I failed to mention that I have had Rapport installed for 
years now, I have not experienced that behavior as you have. Though, I 
am planning on putting the configuration file of my script back next 
week to see if that was what caused the behavior on my system. I will 
try killing Rapport and see if that affects the situation now that you 
have mentioned it.


This comes a while later but I was wrong and you were right.

I had thought since I had Rapport working with cygwin for so long 
without issue that it couldn't be the source of the problem with regards 
to my situation. With the update I did in cygwin something clearly had 
changed causing a conflict. It took a while but I (finally)  uninstalled 
Rapport Trusteer yesterday and the problem was solved. In the meanwhile 
I had gone so far as to install Windows versions of the GNU utilities to 
try my script without cygwin but I had to use cygwin's sort because I 
couldn't work out how to use it under Windows with a different locale 
and it conflicted with join with the case insensitive option unlike 
under cygwin where I could just do  "LANG=en_EN sort -uf". I discovered 
I could use cygwin's sort but if I used it's join while Rapport was 
running my system was messed up afterwards. There were other triggers as 
well, but now I am back to a normal system so thank you very much for 
that advise despite the fact that I ignored it for so long.


Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Extreme Slowness of cygwin commands [SOLVED?]

[Ben Altman]

On 5/27/2016 3:58 PM, b...@theworld.com wrote:

As I said the slowdown was intermittant, Rapport had been running at
least a week or so before the slowdown started which didn't affect for
example cmd or power shell only cygwin that I noticed.

But when I stopped Rapport the slowdown (15+ second process
activation) disappeared instantly.

Needs more investigation but maybe this will help someone else, if I
can save just one child...


I understand and I am not disagreeing with your observations, but in my 
case, and I failed to mention that I have had Rapport installed for 
years now, I have not experienced that behavior as you have. Though, I 
am planning on putting the configuration file of my script back next 
week to see if that was what caused the behavior on my system. I will 
try killing Rapport and see if that affects the situation now that you 
have mentioned it.


Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Extreme Slowness of cygwin commands [SOLVED?]

[Ben Altman]

On 5/26/2016 6:03 PM, b...@theworld.com wrote:

(Windows 7 pro, laptop, SSD, 2.5.1(0.297/5/3))

A few weeks ago I reported extreme slowness in cygwin process
activation after a fresh install. For example something relatively
simple like 'ls' or even 'pwd' would take 15+ seconds to start.

There was no other significant activity on the system and commands
from a command shell or windows power shell started with normal speed.

It just happened again.

Rapport Trusteer Endpoint Protection was running.

It's an IBM product and various banks are beginning to require this is
running before they will let you log in to your account. Typically if
you're not running it when you try to login you'll be stopped with a
"download and install (Trusteer) now" pop-up from the bank site, it's
not something you buy or similar.

I found and clicked their Stop Trusteer Endpoint Protection via the
Start menu.

For some reason beyond my comprehension they require you enter a
captcha but ok no big deal. A popup telling you they are stopping it
lingers for a couple of minutes.

When that popup disappears I went into Task Manager as Administrator,
located Rapport Management Service (something close to that, only
Rapport thing running) and did a right-click end-process.

Slowness immediately disappeared.

I can't say for certain it's related, maybe some other process let go
of something while I was fiddling, but this is the second time this
has worked.

Perhaps someone with more time than I have can try installing
Trusteer, I believe anyone can get it here:

   https://www.trusteer.com/en/support/rapport-windows-start-menu

and reproduce this: Slowing down cygwin a lot while not interfering
with other windows activities and perhaps figure out why.

Unfortunately the interference seems intermittant. It was running for
at least a week before this incident and I hadn't noticed any slowdown
until just now. I do type into a cygwin window probably a few times
per hour when working.

Perhaps someone at IBM could take an interest but likely they'd want
more analysis.

At any rate that's the workaround: Stop Trusteer, see if it helps.


I also have Rapport Trusteer installed from BoA with Firefox and have 
not had the problem when using it. On the other hand in my case I may 
have discovered a connection with Softerra laimex command line utility. 
A script which uses it on a desktop has the slowness issue whenever the 
script is run (after sqlcmd and laimex has completed, the issues surface 
for the rest of the script). I was unable to set up my script on a 
laptop in part due to the need of the use of a VPN and because the IP 
addresses I was given were not "private" (for unknown reasons as it 
should have worked either way just like on my desktop that had the 
slowness issue). Once I replaced all of them with the "private" one's I 
was given, laimex worked to get the data I needed. A week later (today), 
I check the PC that was giving me problems and it was running smoothly 
without the issue happening and this coincided with me updating my 
config file with the updated IP addresses. There are still some puzzling 
things, like why this all started after an update to Cygwin. What I need 
to do now is to set up a test config file with the old addresses and see 
if I am forced to reboot the desktop due to the slowness. The thing is 
that when running Softerra LDAP Administrator and getting data through 
the GUI, it was never an issue.


Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: system lags and dysfunctional after cygwin update

[Ben Altman]

On 5/12/2016 11:57 AM, Warren Young wrote:

On May 12, 2016, at 8:35 AM, Ben Altman <ben...@gmail.com> wrote:

I have been using the same version of ksh for a while

Be specific.  *Which* version?

I can see from your cygcheck.out that you aren’t talking about mksh, the only ksh 
that ships with Cygwin.  Therefore, I assume you mean AT ksh93.  Which 
version did you come from, and which did you upgrade to?
Doing a ksh --version gives me:  version sh (AT Research) 93u+ 
2012-08-01


I haven't upgraded yet because I have not been successful in compiling 
it. My attempt to do so is what began this unusual behavior (when I used 
the setup to get bison). I was compiling under 32-bit Cygwin and if 
successful would try it on the 64-bit version. The current version I am 
using will not work with 64-bit Cygwin.



Incidentally, please consider packaging ksh93u+ (stable) or ksh93v- (beta) for Cygwin.  
It would be nice to have AT ksh for Cygwin, if only for reference and comparison 
purposes.  While doing compatibility testing with mksh, it’s hard to know if any given 
odd behavior is due to an mksh weirdness or if it’s accurately emulating AT ksh.

Relevant:

   http://unix.stackexchange.com/questions/246338/is-the-shell-ksh93-dead
Right now I only have a binary of ksh which I have on all my systems.I 
am not sure what is involved in packaging ksh with Cygwin but would 
definitely be interested in finding out. Though, I was under the 
impression that if the licensing wasn't GNU it would be a problem even 
though it is open source.





did an update of cygwin

 From what version?  Or if you cannot be sure, about how long ago was your last 
update?
I am not sure but at the time it probably was at least 6 months but 
could have been much longer. In the end though I renamed my cygwin 
directory to _cygwin and renamed the branch in the registry as well to 
do a complete reinstall (I did not reinstall babun however) but this did 
not fix the problem. I have a new laptop that I just installed cygwin on 
but have not yet set it up so I can run my report script that would test 
it out on a new installation. Another script that gives me problems 
though worked fine.



I can see from your cygcheck.out that you are now on 1.7.35.  Did you read the 
release notes that strongly recommended that you to move /etc/passwd and 
/etc/group out of the way?  This is especially important in an AD-based 
organization like yours.

What is preventing you from becoming current?  (2.5.1)  I see in your message 
stuff about stuck postinstall scripts, but ipso facto, those are run *after* 
everything is installed, so that doesn’t explain it.
It might be because I ran the cygcheck from babun instead of cygwin. I 
have attached that cygcheck file, though the issue comes up with both.





One result is that everything takes many times longer to complete. E.g. "ls" 
goes from under a second to give a listing to 20 or more seconds.

The usual way to find out what’s happening is to run the problem program under 
strace, then see where the strace output hangs.

Realize that this is not a general problem, so we’re going to be relying on you 
to do much of the debugging.

That said, I don’t think strace will help here, because I don’t think you 
actually have a Cygwin-specific problem.


Another thing that happens is that Internet Explorer stops working - it loads 
unresponsive and then crashes.

Cygwin cannot affect IE, nor vice versa.  The only thing that can affect both 
is the OS kernel or something that ties into it: hardware drivers, antimalware 
software, certain types of malware...


Rebooting fixes the issue until I do something in one of my scripts that 
triggers it again.

Are you certain about that?  I mean, if you can cause the problem within a day 
by running these scripts, have you tried running a whole day without running 
any of those scripts, but doing everything else you’d normally do in that day 
the same way?

I’ll bet that if you try that, you’ll find that the problem reoccurs anyway.
I am pretty sure that it depends on Cygwin. Meaning I have avoided 
cygwin for a day without the issue occurring and can make it happen at 
any time I want to by running my report script (which is why I only run 
it at night now). It takes a couple of minutes for it to download the 
data and then as soon as it prints "generating reports" it hangs and 
everything else does too. I.e. typing a simple command like "ls" will 
take upwards of 20 seconds and all the other side effects. I'll see 
about doing the strace with the script though I will probably have to do 
it next week though.



I see that you’re running Windows 7 Enterprise.  Doesn’t that get you a copy of 
HyperV and a license to run another copy of Windows within it?  Why not install 
a fresh copy of Windows and Cygwin in a HyperV VM, then see if it runs into the 
same problems?  I’ll bet it doesn’t, which will be interesting in its 

Re: system lags and dysfunctional after cygwin update

[Ben Altman]

On 5/12/2016 10:07 PM, Andrey Repin wrote:

Greetings, Ben Altman!


On 5/12/2016 10:44 AM, Marco Atzeri wrote:

On 12/05/2016 16:35, Ben Altman wrote:

  Another thing that happens is that

Internet Explorer stops working - it loads unresponsive and then
crashes. Chrome loads but won't reach any website. Firefox works but
will become unresponsive frequently. Rebooting fixes the issue until I
do something in one of my scripts that triggers it again.

These can not be an effect of cygwin.
Something else cripped your system.

That is the puzzling thing. It only happens when I am running cygwin or
babun

babun is a repackaged Cygwin rip-off.
Delete it and install Cygwin proper.


I don't have any specific need for Babun beyond it having a working mutt 
while my Cygwin installation does not. Perhaps reinstalling Cygwin from 
scratch again would be the easiest remedy.


Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: system lags and dysfunctional after cygwin update

[Ben Altman]

On 5/12/2016 10:44 AM, Marco Atzeri wrote:

On 12/05/2016 16:35, Ben Altman wrote:

 Another thing that happens is that

Internet Explorer stops working - it loads unresponsive and then
crashes. Chrome loads but won't reach any website. Firefox works but
will become unresponsive frequently. Rebooting fixes the issue until I
do something in one of my scripts that triggers it again.


These can not be an effect of cygwin.
Something else cripped your system.


That is the puzzling thing. It only happens when I am running cygwin or 
babun and I can trigger it anytime just by doing ordinary scripting 
things. I can easily reproduce the situation though I obviously try to 
avoid that. The report script used to run twice daily during the day but 
because it now runs for up to 3 hours and causes the situation at the 
point where the joins are done I now run it at night so I can reboot my 
system first thing in the morning. If I run it during the day I would 
have to work with a slow system even after it completed so would need to 
reboot. I now have it set to run at night so I can reboot first thing in 
the morning.


Before getting up to the joins, I grab data off an ldap server and use 
sqlcmd to get data from a sql server. I am getting data for 14 databases 
and I do it concurrently and it appears to work fine. When it reaches 
the joins, suddenly everything slows and becomes unstable. Another 
script I have which I use to search flat files also runs in to a similar 
situation though it doesn't use "join" and I haven't worked out which 
line triggers it.


Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

system lags and dysfunctional after cygwin update

[Ben Altman]

I have been ksh scripting using cygwin for many years over multiple 
Windows versions (currently 7 and 10) without any issues. I have been 
using the same version of ksh for a while and in an attempt to compile a 
more recent version did an update of cygwin whilst I was getting bison 
which has had some severe side effects on my system. This started about 
a month ago and I haven't been able to work out a solution by googling 
or messing around with the installation. It doesn't happen right away 
but is triggered at some point in a script. One result is that 
everything takes many times longer to complete. E.g. "ls" goes from 
under a second to give a listing to 20 or more seconds. One of my 
scripts that I run daily to produce reports which would take 6 minutes 
can take up to 3 hours to complete. Another thing that happens is that 
Internet Explorer stops working - it loads unresponsive and then 
crashes. Chrome loads but won't reach any website. Firefox works but 
will become unresponsive frequently. Rebooting fixes the issue until I 
do something in one of my scripts that triggers it again.


During the update that triggered this, it got stuck in the final part 
dealing with the 0p_000_autorebase.dash script. I eventually went in to 
run it manually (line by line at the command prompt). It succeeded in 
running but did not help unfortunately. I eventually tried removing 
cygwin from my system and installing it again but it did not help. I 
have started moving towards manually pasting things into the command 
line rather than work through scripts as they are more likely to trigger 
the situation. This usually does the trick to cause the issue (this is a 
part of my script for generating a bunch of reports):


for client in $clientlist; do
if [[ -s $client.ldap && -n $(awk '{ if (tolower($1) == 
"username") print "OK"; exit }' $client.rts) ]]; then
join -i -j1 -v1 <(awk 'NR > 2 {if ($1=="") exit; print}' 
${client}.rts | LANG=en_EN sort -uf) \
<(awk -F'","|"$' '$0 ~ /aaaUUID=/ {print $2}' 
${client}.ldap | LANG=en_EN sort -uf) > ${client}.txt &

fi
done

I noticed when I ran 0p_000_autorebase.dash manually one time that it 
took a long time to complete. I could see it running slowly as it logged 
what it was doing on the screen and I let it run all day. When I came in 
the next day it was either still going or had frozen - I didn't wait to 
find out and stopped it and rebooted my system. At some point I 
installed babun which didn't help though at some point mutt stopped 
being able to send mail in cygwin but continued to work through babun 
(/usr/sbin/sendmail would give a memory fault but not in the babun 
installation).


I ran "cygcheck -s -v -r" and have attached the results (I replaced my 
organization's name with aaa and similar though it probably wasn't 
necessary). If anyone could offer some advise or help me out it would be 
greatly appreciated.


Thanks,
Ben


Cygwin Configuration Diagnostics
Current System Time: Thu May 12 14:40:28 2016

Windows 7 Enterprise Ver 6.1 Build 7601 Service Pack 1

Running under WOW64 on AMD64

Path:   C:\Users\bbb\.babun\cygwin\usr\local\bin
C:\Users\bbb\.babun\cygwin\bin
C:\ProgramData\Oracle\Java\javapath
C:\Program Files\Common Files\Microsoft Shared\Microsoft Online Services
C:\Program Files (x86)\Common Files\Microsoft Shared\Microsoft Online 
Services
C:\Program Files (x86)\Common Files\OTG
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0
C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn
C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn
C:\Program Files\Microsoft SQL Server\100\Tools\Binn
C:\Program Files\Microsoft SQL Server\100\DTS\Binn
C:\Program Files (x86)\Microsoft SQL 
Server\100\Tools\Binn\VSShell\Common7\IDE
C:\Program Files (x86)\Bitvise Tunnelier
C:\Program Files (x86)\Hyland\Web ActiveX
C:\Program Files\Microsoft SQL Server\110\Tools\Binn
C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn
C:\Program Files\Microsoft SQL Server\110\DTS\Binn
C:\Program Files (x86)\Microsoft SQL 
Server\110\Tools\Binn\ManagementStudio
C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn
C:\Program Files\TortoiseHg
C:\Users\bbb\AppData\Local\Programs\Python\Python35\Scripts
C:\Users\bbb\AppData\Local\Programs\Python\Python35
C:\Users\bbb\AppData\Local\Programs\Python\Launcher
C:\Users\bbb\.babun
C:\Users\bbb\.babun\cygwin\gnumeric\1.10.16\bin
C:\Users\bbb\.babun\cygwin\home\bbb\scripts
C:\Users\bbb\.babun\cygwin\home\bbb\dev_scripts
.
C:\Users\bbb\.babun\cygwin\gnumeric\1.10.16\bin
C:\Users\b

Q: What is the correct configuration for client and server when using '-nolisten'?

[Ben]

Due to the recent changes to Xorg et al., I've had two major breakages; one
with the update to `xinit` which now requires a `.startxwinrc`, and one
this week with the update to `xorg-server`.
I managed to work around the first breakage, but the second has required me
to roll back to the previous packages for both.
The issue I'm having is that, in spite of Doing It Right (`ssh -f -Y
user@remote_host xterm`), I'm now getting `connect /tmp/.X11-unix/X0:
Connection refused` when trying to connect to my servers (which are also
now, and always have been, running with `-nolisten tcp`).
To be explicit; rolling `xinit` back to 1.3.4-1 and `xorg-server` back to
1.16.3-1 fixed this immediately with no other changes, although I suspect
that the `xinit` downgrade may not be necessary.
What am I doing wrong?

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Need help to replicate old behavior of my X setup scripts with latest Xfree86 update

[Ben Richards]

Up until the recent update to xinit-1.3.4-1 which overhauled X session
handling, I had my session set up nicely for my purposes. With the
following code in my .zshrc and an empty .startxwinrc, when I launched
Cygwin, Xwin.exe would start on display :0.0, it would set the
$DISPLAY variable, and automatically kill the X server when I exited
that terminal. I like mintty so this let me use that as my shell.

.zshrc contents:
=
startxwin  xserver.log
x_start_success=$?
if [[ $x_start_success == 0 ]]; then
   export DISPLAY=:0.0

   pid=`ps | grep '/usr/bin/XWin' | awk '{print $1;}'`
   alias kill_xwin=kill $pid
   if [[ $TMUX ==  ]]  [[ $x_start_success == 0 ]]; then
alias exit=kill $pid ; \exit
   fi
fi

The aforementioned update disrupted this flow so I’m wondering if
anyone has any suggestions on how I can regain a similar sort of
functionality. I don’t like using xterm in Cygwin and would like to
keep using mintty as my main terminal interface. Before, when I ran
startxwin it would launch the server and quit with an error status as
to whether it was successful or not, leaving Xwin.exe running in the
background. Now it stays in the foreground unless I specify otherwise.
However, my startup script relied on the assumption that Xwin.exe was
running by the time startxwinrc finished, which I cannot guarantee if
I run it as a background task. It also used the exit status where if
it was nonzero, I could assume that I already had X running and it
wouldn’t kill the server if I typed ‘exit’ to exit any subsequent
mintty windows I launched with Alt+F2.

I've tried various configurations and read through the man pages but
haven’t come up with an elegant solution other than the idea of
looping on the ‘ps’ until I see Xwin.exe in the list. Is there a
better way?

Sincerely,

Benjamin Richards

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

No shortcuts after default install - how to start cygwin?

[ben modra]

Hi,
After performing a standard (default) install using setup-x86.exe,
there are no shortcuts in the start menu or desktop.  I don't really
mind but don't know how to initiate cygwin without it.

Its a work pc, which means I have little control over the system, and
it has been meddled with quite a bit.  Running XP.  It quite common
for this to happen on installing software, and I usually just make a
desktop shortcut. Must be unusual for others because I can't find any
reference to it in the archives.

Can you please tell me how to run cygwin without the shortcut?

Thanks

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

re: No shortcuts after default install - how to start cygwin?

[ben modra]

Thanks Duncan,

I thought there must be more to it than that - if I run bash.exe then
nothing works. Even basic commands like cygcheck and ls return
'command not found'.
Other ways to start also fail, eg startxwin.exe then a window opens
and immediately closes.

The setup log seems fine to me (no errors) but I don't really know
what to look for.


 Hi,
 After performing a standard (default) install using setup-x86.exe,
 there are no shortcuts in the start menu or desktop.  I don't really
 mind but don't know how to initiate cygwin without it.

 Its a work pc, which means I have little control over the system, and
 it has been meddled with quite a bit.  Running XP.  It quite common
 for this to happen on installing software, and I usually just make a
 desktop shortcut. Must be unusual for others because I can't find any
 reference to it in the archives.

 Can you please tell me how to run cygwin without the shortcut?

 Thanks

I make shortcuts to /cygwin/bin/bash.exe and /cygwin64/bin/bash.exed (I have
both). Perhaps there is a better way to do it, but that works for me,

Cheers ... Duncan.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

RE: Cygwin corrupted taskkill in windows commandline

[Voris, Ben]

 From: Earnie Boyd 
 Sent: Friday, September 21, 2012 11:29 AM
 To: cygwinAtcygwinDOTcom
 Subject: Re: Cygwin corrupted taskkill in windows commandline
 
 On Fri, Sep 21, 2012 at 11:59 AM, Voris, Ben wrote:
  On my system, taskkill is /cygdrive/c/Windows/system32/taskkill.  That is,
  it is not part of Cygwin but is part of Windows.  I suspect either that your
  PATH no longer includes /cygdrive/c/Windows/system32 or that taskkill.exe
  has been removed from that Windows directory.
 
 If it is 64 bit system then it will not be available in a 32 bit
 process such as Cygwin's bash in that directory.  You'll need to look
 at /cygdrive/c/Windows/sysnative/taskkill instead.
 
 -- 
 Earnie
 -- https://sites.google.com/site/earnieboyd


As I read it, 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx  
says that use of sysnative is optional for WOW64 applications.  However, 
http://support.microsoft.com/kb/942589 reports a problem with directly using 
system32 on 64-bit version of Server 2003 and Windows XP.  Perhaps the version 
of Microsoft Windows is the issue?

On my Windows-7 64-bit system, sysnative is not in the path but system32 is.  
On that system, taskkill seems to work from Cygwin.

: file $(type -p taskkill.exe)
/cygdrive/c/Windows/system32/taskkill.exe: PE32 executable (console) Intel 
80386, for MS Windows

: $taskkill /?

TASKKILL [/S system [/U username [/P [password
 { [/FI filter] [/PID processid | /IM imagename] } [/T] [/F]

Description:
This tool is used to terminate tasks by process id (PID) or image name.

...

C:\ dir %SYSTEMROOT%\taskkill.exe /s
...

 Directory of C:\Windows\System32

2009-07-13  18:39   112,640 taskkill.exe
   1 File(s)112,640 bytes

 Directory of C:\Windows\SysWOW64

2009-07-13  18:1477,824 taskkill.exe
   1 File(s) 77,824 bytes

RE: Cygwin corrupted taskkill in windows commandline

[Voris, Ben]

On my system, taskkill is /cygdrive/c/Windows/system32/taskkill.  That is, it 
is not part of Cygwin but is part of Windows.  I suspect either that your PATH 
no longer includes /cygdrive/c/Windows/system32 or that taskkill.exe has been 
removed from that Windows directory.

-Original Message-
From: Hazel 

Hi, I just installed cygwin and now I can not use the native taskkill command
from windows command line, it will only reply with:

'taskkill' is not recognized as an internal or external command, operable
program or batch file.


This installation of Windows XP Pro 32Bit SP3 has been working with no
issues since it was installed a year ago.

I really need to solve this issue as ALOT of tools i have for windows uses
taskkill for aborting DOS programs i use for special equipment such as a
dot-matrix printer.



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Cygwin-corrupted-taskkill-in-windows-commandline-tp92938.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: setup hanging when running postinstall scripts

[Ben Nye]

I am having the same issue as Paul 
(http://sourceware.org/ml/cygwin/2010-11/msg00170.html), but I have already 
tried rebaseall and I have nothing on the BLODA list.

System is:
Windows XP 32 bit (with SP3 and all updates)
Cygwin Version: 1.7.9-1

In fact, I stripped my system down until I literally have almost nothing extra 
running period- but I still get the same issue.  When I try to use setup.exe to 
manage dmalloc- it gives me exit code 254 for every single postinstall script 
(after taking forever to complete each one).  It doesn't matter if I am 
installing it, re-installing it, or uninstalling it- the setup always fails.

The problems in the setup.log.full are noted as such:

For: etc/postistall/000-cygwin-post-install.sh

bash (some number) C:\cygwin\bin\bash.exe *** fatal error - Couldn't allocate 
heap, Win32 error 487

For 000-cygwin-post-install.sh and all other post-install scripts afterward:

bash (some number) fork: child -1 - died waiting for longjmp before 
initialization, retry 0, exit code 0x100, errno 11 (path of the script here): 
fork: retry: Resource temporarily unavailable
bash (some number) C:\cygwin\bin\bash.exe *** fatal error - Couldn't allocate 
heap, Win32 error 487, base 0x4E, top 0x55, reserve_size 454656, 
allocsize 458752, page_const 4096

At this point, I literally have no idea why these things should be failing but 
I am wondering if there is some issue with the setup system itself.  I 
previously had a copy of Cygwin 1.5 on this machine and it never had any 
issues.  

When cleaned out that copy and installed 1.7 I recall that it was working okay, 
but I had a few packages that had some issues with their post-install scripts 
when I tried to use setup to manage my installation (so ultimately, I just 
decided to forgo those packages).

However, I do actually need dmalloc.  Hence I am wondering what the heck the 
problem is.  Here was the list of programs running on the machine on my last 
attempt to run setup.exe, following a full rebaseall in ash:

smss.exe
csrss.exe
winlogon.exe
services.exe
wmiprvse.exe
alg.exe
lsass.exe
explorer.exe
ctfmon.exe
svchost.exe
- DcomLaunch
svchost.exe
- RpcSs
svchost.exe
- Automatic Updates
- BITS
- Com+ Event Manager
- Computer Browser
- Cyptographic Services
- DHCP Client
- Distributed Link Tracking Client
- Error Reporting Service
- Help and Support
- HID
- Network Connections
- NLA
- Remote Access Manager
- Secondary Login
- Security Center
- Server
- Shell Hardware Manager
- System Event Notification
- Task Scheduler
- Telephony
- Themes
- Windows Audio
- Windows Firewall
- WMI
- Windows Time
- Wireless Zero Configuration
- Workstation
svchost.exe
- DNSCache
svchost.exe
- Remote Registry
- SSDP Discovery Service
- TCP/IP NetBIOS LMHosts
svchost.exe
- Webclient
svchost.exe
- Windows Image Acquisition (WMA)
svchost.exe
- HTTP SSL

So that's everything- all the programs and services running.  Nothing BLODA to 
my knowledge.  Heck, if anything there WAS BLODA that should mean that cygwin 
should learn to play nicely with it- all of this stuff is basic WinXP services 
and programs.  So hence... why?  What else could be causing this issue?

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin slow on x64 systems

[Sagi Ben-Akiva]

Hi Magnus,

I applied your patch but I don't notice for any improvement in performance with 
my test case (I still get only 7 lines/sec).


I tried it with several cygwin 1.7.7-1 revisions
Which version of cygwin sources do you use ?
Did you try it with the latest snapshot ?

Thanks,
  Sagi.

Magnus Holmgren wrote:

I did some testing on my 64-bit Vista system, and it appears that
CreateThread is the main cause.


To test this, I removed the call to sigproc_init in dll_crt0_0 and made sure
it was always called in dll_crt0_1 instead. Suddenly the sigp thread started
executing immediately, and its initialization was complete long before
wait_for_sigthread was called.


Since you obviously have a patch, would you mind sharing it, rather than
just your conclusions from said patch?


Not quite ready for commit as is, but here it is:

Index: src/winsup/cygwin/dcrt0.cc
===
RCS file: /cvs/src/src/winsup/cygwin/dcrt0.cc,v
retrieving revision 1.382
diff -r1.382 dcrt0.cc
746,747c746,747
if (!dynamically_loaded)
  sigproc_init ();
---

   //if (!dynamically_loaded)
 //sigproc_init ();

792c792
if (dynamically_loaded)
---

   //if (dynamically_loaded)


   Magnus





--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin slow on x64 systems

[Sagi Ben-Akiva]

On 06/09/2010 19:29, Christopher Faylor wrote:

On Mon, Sep 06, 2010 at 02:31:54PM +0300, Sagi Ben-Akiva wrote:

Hi Magnus,

I applied your patch but I don't notice for any improvement in performance with
my test case (I still get only 7 lines/sec).

I tried it with several cygwin 1.7.7-1 revisions
Which version of cygwin sources do you use ?
Did you try it with the latest snapshot ?


Why are you trying obsolete patches when I've indicated that there is a
fix available in the latest snapshot?

cgf


Because with the snapshot that you published I still get slow performance.
I tried the cygwin1.dll snapshot from 2010-09-01 and from 2010-09-04.

Sagi.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin slow on x64 systems

[Sagi Ben-Akiva]

Edward Lam wrote:


Just curious, has the performance characteristics of your test changed
with the lastest cygwin snapshot? The affected code has moved somewhat
since revision 1.288.



I ran my test script on version 1.7.6 and
on the release from today, i.e. 1.7.7-1,
and performance are even worse.
I get only 5 lines/second.

Sagi.


--
Sagi Ben-Akiva - sagi at graphtech dot co dot il
GraphTech Computer Systems,
www.graphtech.co.il

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Cygwin slow on x64 systems

[Sagi Ben-Akiva]

Hello,

For the last couple of weeks I'm trying to identify the cause for cygwin 
slowdown on x64 machines which was reported by David Morgan about 6 
months ago.


I wrote a little bash script which prints the result of 'date -s' to a 
file in a loop and then counts the number of times the same second 
appears in that file.
I used this script to test all available cygwin revisions snapshots 
(which I downloaded from 
ftp://www.fruitbat.org/pub/cygwin/circa/index.html) for cygwin version 
1.5.19-4.

I was able to identify the exact change which introduce the slowdown.

With my test script for cygwin version 1.5.19-4, snapshot timestamp 
1142005204 I'm able to get ~40 lines/second, but with the same version, 
snapshot timestamp 1142338816 the result is ~18 lines/second.


Using cvsps I was able to generate a patchset which contains all the 
changes between those 2 revisions.
I then applied the changes one by one and built cygwin1.dll for each 
change, then I ran my test script again for each cygwin1.dll version and 
I found that the change to winsup/cygwin/dcrt0.cc from '2006/03/12 
23:57:03' introduce this issue.


The log for this change is :

* dcrt0.cc (dll_crt0_0): Call sigproc_init during init startup.
(_dll_crt0): Don't worry about sync_startup.  Just wait for sigthread here.

This change includes 2 different sub-changes :
1. Moving the call to sigproc_init from dll_crt0_1 function to 
dll_crt0_0 - which doesn't affect performance.


2. a. Moving the call to wait_for_sigthread from dll_crt0_1 to _dll_crt0 
which calls dll_crt0_1.

   b. Deleting the call to WaitForSingleObject,
  i.e. : Don't worry about sync_startup

I can confirm that the 2nd sub-change is the cause for the slowdown.

Any help will be appreciated.

Thank you,
  Sagi.

--

Sagi Ben-Akiva - sagi at graphtech dot co dot il
GraphTech Computer Systems




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: List configuration?

[Ben Kamen]

On 4/29/2010 10:24 AM, Jeremy Bopp wrote:

On 4/29/2010 10:19 AM, Lee Maschmeyer wrote:

Hi folks,

The user's guide requests that people reply to the list, but the default
headers are set up to reply to the sender. This seems a bit strange. I
know it's been this way for ages but I do get tired of realizing I
forgot to change the recipient.


Have you tried using the rely-to-all function of your mailer?  When I do
that with Thunderbird, the recipient is correctly set to only the list
address.  If I simply reply, the recipient is indeed set to the sender
as you say.


The newer thunderbird (I think starting with version 3) has a button Reply to 
List

I try to remember to use that.

 -Ben


--
Ben Kamen - O.D.T., S.P.
--
Home: b...@benjammin.net   http://www.benjammin.net
   http://www.linkedin.com/in/benkamen

'fortune' says:
If your next pot of chili tastes better, it probably is
because of something left out, rather than added.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: [Slightly OT] Need help with GNU ld

[Ben Kamen]

On 4/2/2010 1:20 AM, Christopher Faylor wrote:


This is more than slightly offtopic here.  It's completely offtopic.

Please find another forum.  Sorry.


Not really. I figured there could be a few here who are somewhat gcc saavy. 
Maybe I'd be lucky enough to find someone who could help me learn this... 
offlist.

Never hurts to ask?

Anyway - sorry to bother.

Moving along...

 -Ben

--
Ben Kamen - O.D.T., S.P.
==
Email: bkamen AT benjammin DOT net   Web: http://www.benjammin.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[Slightly OT] Need help with GNU ld

[Ben Kamen]

Hi all,

 I'm sort of lost as to where I might even start with this, and since this 
group is so fluent (I'm guessing) with GCC, I'm hoping someone here can either 
answer or point me to where I can go look.

(I'm looking on the gnu.org's gplusplus list and am not sure if that's a good 
source since it seems kind of dead)

Anyway - here's my problem.

I'm working on an embedded app that uses GCC for its compiler.

I have 2 pieces of code that share common library functions from libc.a like 
memcpy and strlen

Because the two pieces are a bootloader and the application, I would like the 
bootloader to be linked with a completely private set of functions which 
INCLUDEs the library calls they make.

This would duplicate those libc.a calls like memcpy() and strlen() inside the 
bootloader portion.

So my question is (and I might be looking in the wrong place to do this, but it 
seems like 'ld' would take care of it):

How do I tell the ld that for bootloader.o, all library references like 
memcpy() should be inlined/included with that function. I've got all the 
functions in the bootloader corralled into the memory space I want, but the 
functions called in libc.a are shared.

'static' only works for the immediate function while any calls to a libc.a 
function get shared with the main application.

I've already tried the forum for the micro-controller I'm using.. but 
apparently, it's new enough that I'm too far ahead on the curve for anyone else 
to help me. (even from the company)

Thanks in advance and sorry for bugging all of you here.. if I hear crickets, 
I'll try and keep digging elsewhere.

 -Ben


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Cygwin Usage -- Occasional but sunny

[Ben Kamen]

I just wanted to say thanks to everyone who contributes to Cygwin for the great 
tool it is.

I don't use it often, but like these past 2 weeks using openssl, net-snmp, vi 
and tcl from a friendly ksh prompt on windows to do some development from my 
WinXP laptop has been great.

The ease which I showed stuff working to my clients prompted them to go out and 
install/update their own machines.

So - I just wanted to say thanks!

:D

 -Ben

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

SNMP utils

[Ben Kamen]

Hey all,

Pardon this rather neophyte question:


 I have cygwin on my laptop (from years ago) and it has snmp utils loaded that 
I can access from
cygwin. (net-snmp 5.4.1)

Anyway - I don't see net-snmp available from the current list.. so I'm assuming 
I installed it separately..

But it's in my cygwin directory -- so I thought I'd check here first.

Can anyone validate my paranoia? (and forgetfulness)

Thanks a bunch!

 -Ben


--
Ben Kamen - O.D.T., S.P.
=
Email: bkamen AT benjammin DOT net  Web: http://www.benjammin.net

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: SNMP utils

[Ben Kamen]

On 2/15/2010 2:14 PM, Larry Hall (Cygwin) wrote:

On 02/15/2010 02:05 PM, Ben Kamen wrote:

Hey all,

Pardon this rather neophyte question:


I have cygwin on my laptop (from years ago) and it has snmp utils loaded
that I can access from
cygwin. (net-snmp 5.4.1)

Anyway - I don't see net-snmp available from the current list.. so I'm
assuming I installed it separately..

But it's in my cygwin directory -- so I thought I'd check here first.

Can anyone validate my paranoia? (and forgetfulness)


http://cygwin.com/cgi-bin2/package-grep.cgi?grep=net-snmp



Yep. Did that and wondered if I was insane.

Thanks!

 -Ben


--
Ben Kamen - O.D.T., S.P.
=
Email: bkamen AT benjammin DOT net  Web: http://www.benjammin.net


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple