Re: [PATCH v2] Cygwin: clipboard: Fix a bug in read().

[Brian Inglis]

On 2021-12-07 23:30, Mark Geisert wrote:

Brian Inglis wrote:

On 2021-12-07 13:18, Thomas Wolff wrote:

Am 07.12.2021 um 15:23 schrieb Corinna Vinschen:

On Dec  7 23:00, Takashi Yano wrote:

- Fix a bug in fhandler_dev_clipboard::read() that the second read
   fails with 'Bad address'.

Addresses:
   https://cygwin.com/pipermail/cygwin/2021-December/250141.html
---
  winsup/cygwin/fhandler_clipboard.cc | 2 +-
  winsup/cygwin/release/3.3.4 | 6 ++
  2 files changed, 7 insertions(+), 1 deletion(-)
  create mode 100644 winsup/cygwin/release/3.3.4

diff --git a/winsup/cygwin/fhandler_clipboard.cc 
b/winsup/cygwin/fhandler_clipboard.cc

index 0b87dd352..ae10228a7 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, 
size_t& len)

    if (pos < (off_t) clipbuf->cb_size)
  {
    ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - 
pos : len;

-  memcpy (ptr, [1] + pos , ret);
+  memcpy (ptr, (char *) [1] + pos, ret);


I'm always cringing a bit when I see this kind of expression. 
Personally I think (ptr + offset) is easier to read than 
[offset], but of course that's just me. If you agree, would

it be ok to change the above to

   (char *) (clipbuf + 1)

while you're at it?  If you like the ampersand expression more,
it's ok, too, of course. Please push.


In this specific case I think it's actually more confusing because of 
the type mangling that's intended in the clipbuf.

At quick glance, it looks a bit as if the following were meant:

   (char *) clipbuf + 1

I'd even make it clearer like

+  memcpy (ptr, ((char *) [1]) + pos, ret);
or even
+  memcpy (ptr, ((char *) ([1])) + pos, ret);



If the intent is to address:

 clipbuf + pos + 1

use either that or:

 [pos + 1]

to avoid obscuring the intent,
and add comments to make it clearer!


Boy am I kicking myself for screwing up the original here and opening 
this can of worms.  Brian, you'd be correct if clipbuf was (char *) like 
anything-buf often is.  But here it's a struct defining the initial part 
of a dynamic char buffer.


So my original
     [1]
to mean "just after the defining struct" was OK.  But the code needed a 
ptr to some char offset after that and

     [1] + pos
was wrong.  Casting the left term to (char *) would fix it.  But I like 
Corinna's choice of

     (char *) (clipbuf + 1)
to be most elegant and clear of all.  Now enclose that in parens and 
append the char offset so the new expression is

     ((char *) (clipbuf + 1)) + pos


In this context, (char *)clipbuf + sizeof clipbuf would actually be 
clearer. Or hide the expression in a cb_text(clipbuf[,pos?]) macro.


You could make the format and intent clear and obvious by appending 
cb_text[0|1|...] (some C++ compatible form) into cygcb_t in 
sys/clipboard.h.



and all should be golden.  I don't think extra commentary is needed
in code. (I think.)

Where else put commentary?
In this case it should be mandatory, as this is an address hack to 
access the clipboard text, and there were questions about that expression.


--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [PATCH v2] Cygwin: clipboard: Fix a bug in read().

[Mark Geisert]

Brian Inglis wrote:

On 2021-12-07 13:18, Thomas Wolff wrote:


Am 07.12.2021 um 15:23 schrieb Corinna Vinschen:

On Dec  7 23:00, Takashi Yano wrote:

- Fix a bug in fhandler_dev_clipboard::read() that the second read
   fails with 'Bad address'.

Addresses:
   https://cygwin.com/pipermail/cygwin/2021-December/250141.html
---
  winsup/cygwin/fhandler_clipboard.cc | 2 +-
  winsup/cygwin/release/3.3.4 | 6 ++
  2 files changed, 7 insertions(+), 1 deletion(-)
  create mode 100644 winsup/cygwin/release/3.3.4

diff --git a/winsup/cygwin/fhandler_clipboard.cc 
b/winsup/cygwin/fhandler_clipboard.cc

index 0b87dd352..ae10228a7 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, size_t& len)
    if (pos < (off_t) clipbuf->cb_size)
  {
    ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - pos : len;
-  memcpy (ptr, [1] + pos , ret);
+  memcpy (ptr, (char *) [1] + pos, ret);



I'm always cringing a bit when I see this kind of expression. Personally
I think (ptr + offset) is easier to read than [offset], but of course
that's just me.  If you agree, would it be ok to change the above to

   (char *) (clipbuf + 1)

while you're at it?  If you like the ampersand expression more, it's ok,
too, of course.  Please push.


In this specific case I think it's actually more confusing because of the type 
mangling that's intended in the clipbuf.

At quick glance, it looks a bit as if the following were meant:

   (char *) clipbuf + 1

I'd even make it clearer like

+  memcpy (ptr, ((char *) [1]) + pos, ret);
or even
+  memcpy (ptr, ((char *) ([1])) + pos, ret);


If the intent is to address:

 clipbuf + pos + 1

use either that or:

 [pos + 1]

to avoid obscuring the intent,
and add comments to make it clearer!


Boy am I kicking myself for screwing up the original here and opening this can of 
worms.  Brian, you'd be correct if clipbuf was (char *) like anything-buf often 
is.  But here it's a struct defining the initial part of a dynamic char buffer.


So my original
[1]
to mean "just after the defining struct" was OK.  But the code needed a ptr to 
some char offset after that and

[1] + pos
was wrong.  Casting the left term to (char *) would fix it.  But I like Corinna's 
choice of

(char *) (clipbuf + 1)
to be most elegant and clear of all.  Now enclose that in parens and append the 
char offset so the new expression is

((char *) (clipbuf + 1)) + pos
and all should be golden.  I don't think extra commentary is needed in code.

(I think.)

..mark

Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1

[Brian Inglis]

On 2021-12-07 13:16, Ken Brown wrote:
[Redirected from the cygwin list, 
https://cygwin.com/pipermail/cygwin/2021-December/250149.html]


On 12/7/2021 3:08 PM, Ken Brown wrote:

On 12/5/2021 3:50 AM, Achim Gratz wrote:

Autoconf upstream has stated that the 2.7x releases are not fully
backwards compatible.  Cygwin therefore chose to provide a new
autoconf2.7 package (keeping autoconf2.5 available) and modifying the
wrapper script to allow packaging systems to set WANT_AUTOCONF=2.7 to
select a newer autoconf version.  The default (when no explicit
WANT_AUTOCONF is set) is still "2.5", which selects autoconf version
2.69 on Cygwin.


As you explained on IRC earlier today, what you meant is that the 
default for packages built via cygport is still 2.5.



The default will change to "2.7" after some period of
testing.

Cygwin package maintainers are encouraged to set WANT_AUTOCONF=2.7 in
their cygport configuration or in individual cygport files in order to
check for regressions.


I wonder if it would be better to make the default 2.7 in order to more 
strongly encourage maintainers to try the latter.  They can always set 
WANT_AUTOCONF=2.5 if they can't make it work.  But I would bet that most 
difficulties that arise have already been found and fixed by Fedora.


Does Fedora build Windows exes?
Do most packages use libtool?
Remember gnulib? ;^>

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [PATCH v2] Cygwin: clipboard: Fix a bug in read().

[Brian Inglis]

On 2021-12-07 13:18, Thomas Wolff wrote:


Am 07.12.2021 um 15:23 schrieb Corinna Vinschen:

On Dec  7 23:00, Takashi Yano wrote:

- Fix a bug in fhandler_dev_clipboard::read() that the second read
   fails with 'Bad address'.

Addresses:
   https://cygwin.com/pipermail/cygwin/2021-December/250141.html
---
  winsup/cygwin/fhandler_clipboard.cc | 2 +-
  winsup/cygwin/release/3.3.4 | 6 ++
  2 files changed, 7 insertions(+), 1 deletion(-)
  create mode 100644 winsup/cygwin/release/3.3.4

diff --git a/winsup/cygwin/fhandler_clipboard.cc 
b/winsup/cygwin/fhandler_clipboard.cc

index 0b87dd352..ae10228a7 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, size_t& 
len)

    if (pos < (off_t) clipbuf->cb_size)
  {
    ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - 
pos : len;

-  memcpy (ptr, [1] + pos , ret);
+  memcpy (ptr, (char *) [1] + pos, ret);



I'm always cringing a bit when I see this kind of expression. Personally
I think (ptr + offset) is easier to read than [offset], but of course
that's just me.  If you agree, would it be ok to change the above to

   (char *) (clipbuf + 1)

while you're at it?  If you like the ampersand expression more, it's ok,
too, of course.  Please push.


In this specific case I think it's actually more confusing because of 
the type mangling that's intended in the clipbuf.

At quick glance, it looks a bit as if the following were meant:

   (char *) clipbuf + 1

I'd even make it clearer like

+  memcpy (ptr, ((char *) [1]) + pos, ret);
or even
+  memcpy (ptr, ((char *) ([1])) + pos, ret);


If the intent is to address:

clipbuf + pos + 1

use either that or:

[pos + 1]

to avoid obscuring the intent,
and add comments to make it clearer!

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Native ARM support for Cygwin

[Aaron Franke via Cygwin]

Hello Cygwin,
I am wondering what are the plans for adding support for native ARM64 Windows 
to Cygwin.
Currently there are only downloads for x86 (both 32-bit and 64-bit), but not 
for ARM.
I do see in the FAQ that there is a mention of how ARM systems can run the x86 
version of Cygwin, however I am interested in a native ARM64 toolchain if 
possible. By the way, I'm only interested in 64-bit ARM.

Thanks,
Aaron Franke

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

Possible fit?

[Jonathan Thiessen]

Hello Kerri,

Hope I am catching you at a good time.

A little background on me, my name is JT Thiessen, and I am the Chief 
Development Officer for a home service franchise that specializes in providing 
customized window coverings – Budget Blinds.

I am reaching out today because I came across your background and your 
experience at Concept Development, Inc. and it caught my eye.  As the #1 window 
covering franchise in North America, we are actively expanding the franchise in 
California and your profile matches those who have had success with our brand.

I don’t know if you have ever thought about owning your own small business – 
but Budget Blinds is backed by a large and formidable brand, Home Franchise 
Concepts, that will be with you every step of the way.  Owning a Budget Blinds 
can offer a new way to have freedom of flexibility and achieve a better 
work-life balance as your own boss.

Our current franchise owners love our low-overhead, home-based business model 
that continues to see strong sales numbers and profit margins in addition to a 
nearly 70% closing rate.

I would love to discuss this opportunity further.  Please let me know if you 
should have an interest in speaking and learning more.

Thanks,

Jonathan “JT” Thiessen
Chief Development Officer | Home Franchise Concepts, Budget Blinds
jonat...@bgblindsinc.com
franchise.budgetblinds.com

No, thanks.



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

[ANNOUNCEMENT] Updated: autoconf2.5-2.69-4, autoconf2.7-2.71-2

[Achim Gratz]

The autoconf2.5 and autoconf2.7 packages are re-released to fix a
packaging bug that caused identical files being installed by the two
packages and thus interfering with the intended parallel installation of
both.

GNU Autoconf is an extensible package of m4 macros that produce shell
scripts to automatically configure software source code packages. These
scripts can adapt the packages to many kinds of UNIX-like systems
without manual user intervention.  Autoconf creates a configuration
script for a package from a template file that lists the operating
system features that the package can use, in the form of m4 macro calls.

Multiple versions of Autoconf can be installed at the same time --
the autoconf wrapper choses among them.


Cygwin Packaging Notes
==

Autoconf upstream has stated that the 2.7x releases are not fully
backwards compatible.  Cygwin therefore chose to provide a new
autoconf2.7 package (keeping autoconf2.5 available) and modifying the
wrapper script to allow packaging systems to set WANT_AUTOCONF=2.7 to
select a newer autoconf version.  The default in cygport (when no
explicit WANT_AUTOCONF is set) is still "2.5", which selects autoconf
version 2.69 on Cygwin.  The default will change to "2.7" after some
period of testing.  Outside cygport the wrapper will select the latest
autoconf version absent any other definition via WANT_AUTOCONF.

Cygwin package maintainers are encouraged to set WANT_AUTOCONF=2.7 in
their cygport configuration or in individual cygport files in order to
check for regressions.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

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

Updated: autoconf2.5-2.69-4, autoconf2.7-2.71-2

[Achim Gratz]

The autoconf2.5 and autoconf2.7 packages are re-released to fix a
packaging bug that caused identical files being installed by the two
packages and thus interfering with the intended parallel installation of
both.

GNU Autoconf is an extensible package of m4 macros that produce shell
scripts to automatically configure software source code packages. These
scripts can adapt the packages to many kinds of UNIX-like systems
without manual user intervention.  Autoconf creates a configuration
script for a package from a template file that lists the operating
system features that the package can use, in the form of m4 macro calls.

Multiple versions of Autoconf can be installed at the same time --
the autoconf wrapper choses among them.


Cygwin Packaging Notes
==

Autoconf upstream has stated that the 2.7x releases are not fully
backwards compatible.  Cygwin therefore chose to provide a new
autoconf2.7 package (keeping autoconf2.5 available) and modifying the
wrapper script to allow packaging systems to set WANT_AUTOCONF=2.7 to
select a newer autoconf version.  The default in cygport (when no
explicit WANT_AUTOCONF is set) is still "2.5", which selects autoconf
version 2.69 on Cygwin.  The default will change to "2.7" after some
period of testing.  Outside cygport the wrapper will select the latest
autoconf version absent any other definition via WANT_AUTOCONF.

Cygwin package maintainers are encouraged to set WANT_AUTOCONF=2.7 in
their cygport configuration or in individual cygport files in order to
check for regressions.

-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Re: [PATCH v2] Cygwin: clipboard: Fix a bug in read().

[Thomas Wolff]

Am 07.12.2021 um 15:23 schrieb Corinna Vinschen:

On Dec  7 23:00, Takashi Yano wrote:

- Fix a bug in fhandler_dev_clipboard::read() that the second read
   fails with 'Bad address'.

Addresses:
   https://cygwin.com/pipermail/cygwin/2021-December/250141.html
---
  winsup/cygwin/fhandler_clipboard.cc | 2 +-
  winsup/cygwin/release/3.3.4 | 6 ++
  2 files changed, 7 insertions(+), 1 deletion(-)
  create mode 100644 winsup/cygwin/release/3.3.4

diff --git a/winsup/cygwin/fhandler_clipboard.cc 
b/winsup/cygwin/fhandler_clipboard.cc
index 0b87dd352..ae10228a7 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, size_t& len)
if (pos < (off_t) clipbuf->cb_size)
{
  ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - pos : len;
- memcpy (ptr, [1] + pos , ret);
+ memcpy (ptr, (char *) [1] + pos, ret);

I'm always cringing a bit when I see this kind of expression. Personally
I think (ptr + offset) is easier to read than [offset], but of course
that's just me.  If you agree, would it be ok to change the above to

   (char *) (clipbuf + 1)

while you're at it?  If you like the ampersand expression more, it's ok,
too, of course.  Please push.
In this specific case I think it's actually more confusing because of 
the type mangling that's intended in the clipbuf.

At quick glance, it looks a bit as if the following were meant:

  (char *) clipbuf + 1


I'd even make it clearer like

+ memcpy (ptr, ((char *) [1]) + pos, ret);
or even
+ memcpy (ptr, ((char *) ([1])) + pos, ret);

Thomas

Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1

[Ken Brown]

[Redirected from the cygwin list, 
https://cygwin.com/pipermail/cygwin/2021-December/250149.html]


On 12/7/2021 3:08 PM, Ken Brown wrote:

On 12/5/2021 3:50 AM, Achim Gratz wrote:

Autoconf upstream has stated that the 2.7x releases are not fully
backwards compatible.  Cygwin therefore chose to provide a new
autoconf2.7 package (keeping autoconf2.5 available) and modifying the
wrapper script to allow packaging systems to set WANT_AUTOCONF=2.7 to
select a newer autoconf version.  The default (when no explicit
WANT_AUTOCONF is set) is still "2.5", which selects autoconf version
2.69 on Cygwin.


As you explained on IRC earlier today, what you meant is that the default for 
packages built via cygport is still 2.5.



The default will change to "2.7" after some period of
testing.

Cygwin package maintainers are encouraged to set WANT_AUTOCONF=2.7 in
their cygport configuration or in individual cygport files in order to
check for regressions.


I wonder if it would be better to make the default 2.7 in order to more strongly 
encourage maintainers to try the latter.  They can always set WANT_AUTOCONF=2.5 
if they can't make it work.  But I would bet that most difficulties that arise 
have already been found and fixed by Fedora.


Ken

Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1

[Ken Brown]

On 12/5/2021 3:50 AM, Achim Gratz wrote:

Autoconf upstream has stated that the 2.7x releases are not fully
backwards compatible.  Cygwin therefore chose to provide a new
autoconf2.7 package (keeping autoconf2.5 available) and modifying the
wrapper script to allow packaging systems to set WANT_AUTOCONF=2.7 to
select a newer autoconf version.  The default (when no explicit
WANT_AUTOCONF is set) is still "2.5", which selects autoconf version
2.69 on Cygwin.


As you explained on IRC earlier today, what you meant is that the default for 
packages built via cygport is still 2.5.



The default will change to "2.7" after some period of
testing.

Cygwin package maintainers are encouraged to set WANT_AUTOCONF=2.7 in
their cygport configuration or in individual cygport files in order to
check for regressions.


I have a comment about this, but I'll follow up on cygwin-apps.

Ken

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

Re: vboxsharedfs - Too many levels of symbolic links

[Corinna Vinschen]

On Dec  8 00:32, Takashi Yano wrote:
> On Tue, 7 Dec 2021 15:57:56 +0100
> Corinna Vinschen wrote:
> > On Dec  7 09:46, Takashi Yano wrote:
> > > I think '/cygdrive/z/..' should be '/cygdrive', however,
> > > in current cygwin, it is interpreted into '//VBoxSrv'.
> > > 
> > > Is this as you intended?
> > > 
> > > With my patch which stops to treat UNC path as symlink,
> > > '/cygdrive/z/..' returns '/cygdrive'.
> > 
> > Yeah, but...
> > 
> > ...what bugs me is that *every* UNC path is treated this way with
> > that patch.  If you have a path like /cygdrive/x/a/b/c, with x:
> > being a virtual drive pointing to //server/share, and with "b"
> > being a symlink to "syml", what you get back is either
> > 
> >   //server/share/a/syml/c
> > 
> > without, or
> > 
> >   /cygdrive/x/a/b/c
> > 
> > with your patch.  What we would like to get back is
> > 
> >   /cygdrive/x/a/syml/c
> 
> With my patch, above case behaves like:
> 
> $ mount
> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)
> $ cd /cygdrive/z
> $ mkdir -p aa/syml/cc
> $ ln -s syml aa/bb
> $ cd aa/bb/cc
> $ /bin/pwd
> /cygdrive/z/aa/syml/cc
> $
> 
> Isn't this what you would like?

Sorry, I wasn't expressing myself clearly.  The end result is what is
expected, yes.  But that's the result of the full path_conv conversion,
which wasn't what I was up to.

The idea of the GFPNBH call is to short-circuit the path_conv handling
in case we have native Windows symlinks in the path.  My example above
was only considering what comes out of the `if ((pc_flags & ...) { ... }
' expression starting in line 3485 (assuming "b" is a native symlink).

What I mean is this: Your patch disregards the entire string returned by
GFPNBH, if the returned path is an UNC path, no matter what.

But what if the incoming path already *was* an UNC path, and potentially
contains native symlinks?  In that case you have no reason to disregard
the resulting path from GFPNBH.

And if it was a drive letter path, wouldn't it be nicer to just convert
the UNC path prefix back to the drive letter and keep the rest of the
final path intact?

However, both of these scenarios require extra code, which isn't that
important for now, so, never mind.


Corinna

-- 
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: vboxsharedfs - Too many levels of symbolic links

[Takashi Yano]

On Wed, 8 Dec 2021 00:32:49 +0900
Takashi Yano wrote:
> With my patch, above case behaves like:
> 
> $ mount
> C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
> C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
> C:/cygwin on / type ntfs (binary,auto)
> C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
> D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
> Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)
> $ cd /cygdrive/z
> $ mkdir -p aa/syml/cc
> $ ln -s syml aa/bb
> $ cd aa/bb/cc
> $ /bin/pwd
> /cygdrive/z/aa/syml/cc
> $

$ cygpath -a .
/cygdrive/z/aa/syml/cc/
$ echo -e 'all:\n\t@echo CURDIR=$(CURDIR)' > Makefile
$ make -C .
make: Entering directory '/cygdrive/z/aa/syml/cc'
CURDIR=/cygdrive/z/aa/syml/cc
make: Leaving directory '/cygdrive/z/aa/syml/cc'

> Isn't this what you would like?

-- 
Takashi Yano 

-- 
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: Orphaned Packages in Packages List

[Marco Atzeri]

On 07.12.2021 16:19, Fenlason, Allen [US] (ES) wrote:

I am trying to understand the process for managing packages that are listed on 
the CygWin Packages list page.

This specifically refers to https://cygwin.com/packages/package_list.html.

In reading the CygWin Package Contributor's Guide, it indicates that packages 
without active maintainers are removed from distribution. Does that just mean 
it is not included as part of the base installation of CygWin, or is there also 
a process for removing these from the Package List site?


Hi Allen

we are not removing them; just not updating until a new maintainer
adopts them, or some one update them
(usually for solving dependency issue)

The full list of packages and maintainers is here:
https://www.cygwin.com/cygwin-pkg-maint

Regards
Marco

--
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: vboxsharedfs - Too many levels of symbolic links

[Takashi Yano]

On Tue, 7 Dec 2021 15:57:56 +0100
Corinna Vinschen wrote:
> On Dec  7 09:46, Takashi Yano wrote:
> > I think '/cygdrive/z/..' should be '/cygdrive', however,
> > in current cygwin, it is interpreted into '//VBoxSrv'.
> > 
> > Is this as you intended?
> > 
> > With my patch which stops to treat UNC path as symlink,
> > '/cygdrive/z/..' returns '/cygdrive'.
> 
> Yeah, but...
> 
> ...what bugs me is that *every* UNC path is treated this way with
> that patch.  If you have a path like /cygdrive/x/a/b/c, with x:
> being a virtual drive pointing to //server/share, and with "b"
> being a symlink to "syml", what you get back is either
> 
>   //server/share/a/syml/c
> 
> without, or
> 
>   /cygdrive/x/a/b/c
> 
> with your patch.  What we would like to get back is
> 
>   /cygdrive/x/a/syml/c

With my patch, above case behaves like:

$ mount
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto)
D: on /cygdrive/d type iso9660 (binary,posix=0,user,noumount,auto)
Z: on /cygdrive/z type vboxsharedfolderfs (binary,posix=0,user,noumount,auto)
$ cd /cygdrive/z
$ mkdir -p aa/syml/cc
$ ln -s syml aa/bb
$ cd aa/bb/cc
$ /bin/pwd
/cygdrive/z/aa/syml/cc
$

Isn't this what you would like?


> So the real problem is not that we have an UNC path, but the fact that
> the drive letter expression is (correctly, but unwanted) converted to
> the matching UNC path by GetFinalPathNameByHandle.
> 
> Bottom line is, your patch is ok, please apply.  It would be nice,
> though, if we could just avoid the drive: -> UNC path conversion and
> keep the rest.


-- 
Takashi Yano 

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

Orphaned Packages in Packages List

[Fenlason, Allen [US] (ES)]

I am trying to understand the process for managing packages that are listed on 
the CygWin Packages list page. 

This specifically refers to https://cygwin.com/packages/package_list.html.

In reading the CygWin Package Contributor's Guide, it indicates that packages 
without active maintainers are removed from distribution. Does that just mean 
it is not included as part of the base installation of CygWin, or is there also 
a process for removing these from the Package List site?

Thanks,
ALLEN 


-- 
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: vboxsharedfs - Too many levels of symbolic links

[Corinna Vinschen]

On Dec  7 09:46, Takashi Yano wrote:
> On Mon, 6 Dec 2021 19:55:27 +0900
> Takashi Yano wrote:
> > First, I think the same. However, with this patch, it sometimes causes
> > hang for a few seconds around the code:
> [...]
> > with path_copy of "//VBoxSrv". I am not sure why.

That's expected and nothing really to worry about.  It's the network
environment access in fhandler_netdrive.


I have this on the radar already, because the WNet stuff in there has
been broken by Microsoft with certain updates to Windows 10.  A SMB
security fix has deliberately left behind the WNet calls to enumerate
the network environment, because they rely on functionality of older SMB
versions.


> > 
> > In addition,
> > https://cygwin.com/pipermail/cygwin/2021-December/250103.html
> > still needs fix.
> 
> Moreover, this has a problem with "ls -al /cygdrive/z".
> The information for ".." is not retrieved correctly.
> 
> drwxr-xr-x 1 yano None   0 Dec  6 13:54 .
> d? ? ??  ?? ..
> -rw-r--r-- 1 yano None  29 Dec  4 07:45 Makefile
> -rw-r--r-- 1 yano None  17 Dec  6 13:18 a
> drwxr-xr-x 1 yano None   0 Dec  6 08:59 aaa
> lrwxrwxrwx 1 yano None   1 Dec  6 13:54 b -> a
> -rwxr-xr-x 1 yano None 3278626 Dec  7 09:07 cygwin0.dll
> -rwxr-xr-x 1 yano None 3549860 Dec  6 08:51 cygwin0.dll.64
> -rw-r--r-- 1 yano None   0 Dec  3 22:16 testfile.txt
> 
> I think '/cygdrive/z/..' should be '/cygdrive', however,
> in current cygwin, it is interpreted into '//VBoxSrv'.
> 
> Is this as you intended?
> 
> With my patch which stops to treat UNC path as symlink,
> '/cygdrive/z/..' returns '/cygdrive'.

Yeah, but...

...what bugs me is that *every* UNC path is treated this way with
that patch.  If you have a path like /cygdrive/x/a/b/c, with x:
being a virtual drive pointing to //server/share, and with "b"
being a symlink to "syml", what you get back is either

  //server/share/a/syml/c

without, or

  /cygdrive/x/a/b/c

with your patch.  What we would like to get back is

  /cygdrive/x/a/syml/c

So the real problem is not that we have an UNC path, but the fact that
the drive letter expression is (correctly, but unwanted) converted to
the matching UNC path by GetFinalPathNameByHandle.

Bottom line is, your patch is ok, please apply.  It would be nice,
though, if we could just avoid the drive: -> UNC path conversion and
keep the rest.


Thanks,
Corinna

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

[PATCH v3] Cygwin: clipboard: Fix a bug in read().

[Takashi Yano]

- Fix a bug in fhandler_dev_clipboard::read() that the second read
  fails with 'Bad address'.

Addresses:
  https://cygwin.com/pipermail/cygwin/2021-December/250141.html
---
 winsup/cygwin/fhandler_clipboard.cc | 2 +-
 winsup/cygwin/release/3.3.4 | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)
 create mode 100644 winsup/cygwin/release/3.3.4

diff --git a/winsup/cygwin/fhandler_clipboard.cc 
b/winsup/cygwin/fhandler_clipboard.cc
index 0b87dd352..05f54ffb3 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, size_t& len)
   if (pos < (off_t) clipbuf->cb_size)
{
  ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - pos : len;
- memcpy (ptr, [1] + pos , ret);
+ memcpy (ptr, (char *) (clipbuf + 1) + pos, ret);
  pos += ret;
}
 }
diff --git a/winsup/cygwin/release/3.3.4 b/winsup/cygwin/release/3.3.4
new file mode 100644
index 0..f1c32a1a5
--- /dev/null
+++ b/winsup/cygwin/release/3.3.4
@@ -0,0 +1,6 @@
+Bug Fixes
+-
+
+- Fix a bug in fhandler_dev_clipboard::read() that the second read
+  fails with 'Bad address'.
+  Addresses: https://cygwin.com/pipermail/cygwin/2021-December/250141.html
-- 
2.34.1

Re: [PATCH v2] Cygwin: clipboard: Fix a bug in read().

[Corinna Vinschen]

On Dec  7 23:00, Takashi Yano wrote:
> - Fix a bug in fhandler_dev_clipboard::read() that the second read
>   fails with 'Bad address'.
> 
> Addresses:
>   https://cygwin.com/pipermail/cygwin/2021-December/250141.html
> ---
>  winsup/cygwin/fhandler_clipboard.cc | 2 +-
>  winsup/cygwin/release/3.3.4 | 6 ++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>  create mode 100644 winsup/cygwin/release/3.3.4
> 
> diff --git a/winsup/cygwin/fhandler_clipboard.cc 
> b/winsup/cygwin/fhandler_clipboard.cc
> index 0b87dd352..ae10228a7 100644
> --- a/winsup/cygwin/fhandler_clipboard.cc
> +++ b/winsup/cygwin/fhandler_clipboard.cc
> @@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, size_t& len)
>if (pos < (off_t) clipbuf->cb_size)
>   {
> ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - pos : len;
> -   memcpy (ptr, [1] + pos , ret);
> +   memcpy (ptr, (char *) [1] + pos, ret);

I'm always cringing a bit when I see this kind of expression. Personally
I think (ptr + offset) is easier to read than [offset], but of course
that's just me.  If you agree, would it be ok to change the above to

  (char *) (clipbuf + 1)

while you're at it?  If you like the ampersand expression more, it's ok,
too, of course.  Please push.


Thanks,
Corinna

Re: [PATCH] Cygwin: Update configure.ac to use AC_CONFIG_HEADERS

[Corinna Vinschen]

On Dec  7 13:29, Jon Turney wrote:
> This avoids warning with autoconf >= 2.70:
> 
>   configure.ac:47: warning: The macro `AC_CONFIG_HEADER' is obsolete.
> 
> AC_CONFIG_HEADERS has been supported since before autconf 2.59, the
> minimum version we can be using, controlled by AC_PREREQ.
> ---
>  winsup/configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/winsup/configure.ac b/winsup/configure.ac
> index 9a11411ab..79e78a5fc 100644
> --- a/winsup/configure.ac
> +++ b/winsup/configure.ac
> @@ -44,7 +44,7 @@ 
> AC_ARG_WITH([cross-bootstrap],[AS_HELP_STRING([--with-cross-bootstrap],[do 
> not b
>  
>  AC_CYGWIN_INCLUDES
>  
> -AC_CONFIG_HEADER(cygwin/config.h)
> +AC_CONFIG_HEADERS([cygwin/config.h])
>  
>  AC_CHECK_TOOL(AR, ar, ar)
>  AC_CHECK_TOOL(AS, as, as)
> -- 
> 2.34.1

Sure thing.


Thanks,
Corinna

[PATCH v2] Cygwin: clipboard: Fix a bug in read().

[Takashi Yano]

- Fix a bug in fhandler_dev_clipboard::read() that the second read
  fails with 'Bad address'.

Addresses:
  https://cygwin.com/pipermail/cygwin/2021-December/250141.html
---
 winsup/cygwin/fhandler_clipboard.cc | 2 +-
 winsup/cygwin/release/3.3.4 | 6 ++
 2 files changed, 7 insertions(+), 1 deletion(-)
 create mode 100644 winsup/cygwin/release/3.3.4

diff --git a/winsup/cygwin/fhandler_clipboard.cc 
b/winsup/cygwin/fhandler_clipboard.cc
index 0b87dd352..ae10228a7 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, size_t& len)
   if (pos < (off_t) clipbuf->cb_size)
{
  ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - pos : len;
- memcpy (ptr, [1] + pos , ret);
+ memcpy (ptr, (char *) [1] + pos, ret);
  pos += ret;
}
 }
diff --git a/winsup/cygwin/release/3.3.4 b/winsup/cygwin/release/3.3.4
new file mode 100644
index 0..f1c32a1a5
--- /dev/null
+++ b/winsup/cygwin/release/3.3.4
@@ -0,0 +1,6 @@
+Bug Fixes
+-
+
+- Fix a bug in fhandler_dev_clipboard::read() that the second read
+  fails with 'Bad address'.
+  Addresses: https://cygwin.com/pipermail/cygwin/2021-December/250141.html
-- 
2.34.1

[PATCH] Cygwin: clipboard: Fix a bug in read().

[Takashi Yano]

- Fix a bug in fhandler_clipboard::read() that the second read fails
  with 'Bad address'.

Addresses:
  https://cygwin.com/pipermail/cygwin/2021-December/250141.html
---
 winsup/cygwin/fhandler_clipboard.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/fhandler_clipboard.cc 
b/winsup/cygwin/fhandler_clipboard.cc
index 0b87dd352..ae10228a7 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -229,7 +229,7 @@ fhandler_dev_clipboard::read (void *ptr, size_t& len)
   if (pos < (off_t) clipbuf->cb_size)
{
  ret = (len > (clipbuf->cb_size - pos)) ? clipbuf->cb_size - pos : len;
- memcpy (ptr, [1] + pos , ret);
+ memcpy (ptr, (char *) [1] + pos, ret);
  pos += ret;
}
 }
-- 
2.34.1

Re: clipboard broken

[Takashi Yano]

On Tue, 7 Dec 2021 12:51:54 +0100
Thomas Wolff wrote:
> I cannot copy more than precisely 128KB into /dev/clipboard. Copying it 
> back will report Bad address.
> Worked in 3.3.0, broken in 3.3.2 (did not test 3.3.1).

Thanks for the report. I found the cause.
I will submit a patch for this issue shortly.

-- 
Takashi Yano 

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

[PATCH] Cygwin: Update configure.ac to use AC_CONFIG_HEADERS

[Jon Turney]

This avoids warning with autoconf >= 2.70:

  configure.ac:47: warning: The macro `AC_CONFIG_HEADER' is obsolete.

AC_CONFIG_HEADERS has been supported since before autconf 2.59, the
minimum version we can be using, controlled by AC_PREREQ.
---
 winsup/configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/configure.ac b/winsup/configure.ac
index 9a11411ab..79e78a5fc 100644
--- a/winsup/configure.ac
+++ b/winsup/configure.ac
@@ -44,7 +44,7 @@ 
AC_ARG_WITH([cross-bootstrap],[AS_HELP_STRING([--with-cross-bootstrap],[do not b
 
 AC_CYGWIN_INCLUDES
 
-AC_CONFIG_HEADER(cygwin/config.h)
+AC_CONFIG_HEADERS([cygwin/config.h])
 
 AC_CHECK_TOOL(AR, ar, ar)
 AC_CHECK_TOOL(AS, as, as)
-- 
2.34.1

clipboard broken

[Thomas Wolff]

I cannot copy more than precisely 128KB into /dev/clipboard. Copying it 
back will report Bad address.

Worked in 3.3.0, broken in 3.3.2 (did not test 3.3.1).
Thomas

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