Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Martin Rauscher]

> Not clear why you expect that a Windows specific tag as
> IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
>
> Moreover all the documentation from MS seems
>
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
>
> that seems a bit short to help third party in properly using it.
>
> Regards
> Marco


For some context, the reason why this is getting some attention is
(probably) this:
Windows is getting its own Package Manager and it's based on UWP and
thus this issue appears for everybody trying out WinGet + Cygwin (or
Git for Windows etc).
Issue on their side: https://github.com/microsoft/winget-cli/issues/228

This is truly a pretty weird feature of Windows/NTFS where there was
not much reason to support it before, but with WinGet this will become
a much requested feature on no time.

Best Regards,
Martin

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Corinna Vinschen]

On Jun  9 21:18, Martin Rauscher via Cygwin wrote:
> > Not clear why you expect that a Windows specific tag as
> > IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
> >
> > Moreover all the documentation from MS seems
> >
> > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
> >
> > that seems a bit short to help third party in properly using it.
> >
> > Regards
> > Marco
> 
> 
> For some context, the reason why this is getting some attention is
> (probably) this:
> Windows is getting its own Package Manager and it's based on UWP and
> thus this issue appears for everybody trying out WinGet + Cygwin (or
> Git for Windows etc).
> Issue on their side: https://github.com/microsoft/winget-cli/issues/228
> 
> This is truly a pretty weird feature of Windows/NTFS where there was
> not much reason to support it before, but with WinGet this will become
> a much requested feature on no time.

Two questions:

- Do you expect Cygwin to handle IO_REPARSE_TAG_APPEXECLINK reparse
  points as ordinary executable files, or as symlinks pointing to
  executable files?

- If as symlinks, we'd need somebody to run the test app from
  https://cygwin.com/pipermail/cygwin/2020-March/244180.html on such
  symlinks, to see how they look on the inside.  This is required to let
  Cygwin handle them as symlinks correctly.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Kagami Rosylight]

Hi Cygwin community,

I found that Cygwin can’t run UWP based CLI tools, as they expose their executables as reparse points with the tag IO_REPARSE_TAG_APPEXECLINK which Cygwin does not support.

Way to reproduce this issue on Cygwin:

1. Install Python from Microsoft Store: https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l (assuming you don’t already have python3.8 on your PATH.)
2. Try running `python3.8` on Cygwin. It will say “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8: Permission denied”
3. Check it’s real path by `get-childitem -path C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on PowerShell. It’s `C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`.
4. Try running python again with that path. This succeeds.

I posted this issue on MSYS2 GitHub repo (https://github.com/msys2/MSYS2-packages/issues/1943) but I think Cygwin is the right place to file this.

Relevant prior works:

* Python https://github.com/python/cpython/commit/df2d4a6f3d5da2839c4fc11d31511c8e028daf2c
* libuv https://github.com/libuv/libuv/commit/e7ebae26247d2fee0a04547eb7f9aa8f78d4a642
* PowerShell https://github.com/PowerShell/PowerShell/pull/10331

Thanks,

-Kagami

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Marco Atzeri]

On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote:
> Hi Cygwin community,
> 
> I found that Cygwin can’t run UWP based CLI tools, as they expose their executables as reparse points with the tag IO_REPARSE_TAG_APPEXECLINK which Cygwin does not support.
> 
> Way to reproduce this issue on Cygwin:
> 
> 1. Install Python from Microsoft Store: https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l (assuming you don’t already have python3.8 on your PATH.)
> 2. Try running `python3.8` on Cygwin. It will say “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8: Permission denied”
> 3. Check it’s real path by `get-childitem -path C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on PowerShell. It’s `C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`.
> 4. Try running python again with that path. This succeeds.
> 
> I posted this issue on MSYS2 GitHub repo (https://github.com/msys2/MSYS2-packages/issues/1943) but I think Cygwin is the right place to file this.
> 
> Relevant prior works:
> 
> * Python https://github.com/python/cpython/commit/df2d4a6f3d5da2839c4fc11d31511c8e028daf2c
> * libuv https://github.com/libuv/libuv/commit/e7ebae26247d2fee0a04547eb7f9aa8f78d4a642
> * PowerShell https://github.com/PowerShell/PowerShell/pull/10331
> 
> Thanks,
> 
> -Kagami
> 

Not clear why you expect that a Windows specific tag as
IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?

Moreover all the documentation from MS seems

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4

that seems a bit short to help third party in properly using it.

Regards
Marco


PS: Python 3.8 is available as Cygwin binary

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Brian Inglis]

On 2020-05-23 09:50, Marco Atzeri via Cygwin wrote:
> On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote:

>> I found that Cygwin can’t run UWP based CLI tools, as they expose their
>> executables as reparse points with the tag IO_REPARSE_TAG_APPEXECLINK which
>> Cygwin does not support.
>>
>> Way to reproduce this issue on Cygwin:
>>
>> 1. Install Python from Microsoft Store:
>> https://www.microsoft.com/en-us/p/python-38/9mssztt1n39l (assuming you don’t
>> already have python3.8 on your PATH.)
>> 2. Try running `python3.8` on Cygwin. It will say
>> “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8:
>> Permission denied”
>> 3. Check it’s real path by `get-childitem -path
>> C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on
>> PowerShell. It’s `C:\Program
>> Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`.
>>
>> 4. Try running python again with that path. This succeeds.
>>
>> I posted this issue on MSYS2 GitHub repo
>> (https://github.com/msys2/MSYS2-packages/issues/1943) but I think Cygwin is
>> the right place to file this.
>>
>> Relevant prior works:
>>
>> * Python
>> https://github.com/python/cpython/commit/df2d4a6f3d5da2839c4fc11d31511c8e028daf2c
>> * libuv
>> https://github.com/libuv/libuv/commit/e7ebae26247d2fee0a04547eb7f9aa8f78d4a642
>> * PowerShell https://github.com/PowerShell/PowerShell/pull/10331

> Not clear why you expect that a Windows specific tag as
> IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
> 
> Moreover all the documentation from MS seems
> 
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
> 
> that seems a bit short to help third party in properly using it.

I think the general point being made is that /some/ Windows tools can not be run
from Cygwin.
I wonder what happens if the OP runs "cygstart python3.8"?

-- 
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 IEC units and prefixes, physical quantities in SI.]

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Marco Atzeri]

Reply always with mailing list in copy, please
and bottom posting as standard

On 23.05.2020 18:34, Kagami Rosylight wrote:
> Hi Marco,
> 
>>Not clear why you expect that a Windows specific tag as
> IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
> 
> https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/path.cc;h=36aa8278fd8495bdfe5ec82b8c36d7d3d7881ebb;hb=refs/heads/master#l2473 
> 
> 
> Because Cygwin already supports common reparse points (such as symlinks) 
> and APPEXECLINK is also a common one used by Microsoft Store. This issue 
> causes some CLI tools depending on MSYS2 (which again on Cygwin) to fail 
> calling system Python executable.
> 
>  > that seems a bit short to help third party in properly using it.
> 
> Good point, and that’s why I only could provide the prior works. 
> REPARSE_DATA_BUFFER_APPEXECLINK in the PowerShell patch shows how the 
> structure look like, but this definitely needs an official 
> documentation. I don’t think it’s a strict blocker given that there are 
> public working patches, though.
> 
> -Kagami
> 
> *From: *Marco Atzeri 
> *Sent: *Saturday, 23 May 2020 5:50 PM
> *To: *cygwin@cygwin.com , saschanaz@outlook.com 
> *Subject: *Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK
> 
> On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote:
>  > Hi Cygwin community,
>  >
>  > I found that Cygwin can’t run UWP based CLI tools, as they expose 
> their executables as reparse points with the tag 
> IO_REPARSE_TAG_APPEXECLINK which Cygwin does not support.
>  >
>  > Way to reproduce this issue on Cygwin:
>  >
>  > 1. Install Python from Microsoft Store: 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fp%2Fpython-38%2F9mssztt1n39l&data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637258458551804597&sdata=NnwQ27A9WsjWdilY6nqF3WR0WnGUvzzeHoajB3onPpo%3D&reserved=0 
> (assuming you don’t already have python3.8 on your PATH.)
>  > 2. Try running `python3.8` on Cygwin. It will say 
> “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8: 
> Permission denied”
>  > 3. Check it’s real path by `get-childitem -path 
> C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on 
> PowerShell. It’s `C:\Program 
> Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`.
>  > 4. Try running python again with that path. This succeeds.
>  >
>  > I posted this issue on MSYS2 GitHub repo 
> (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmsys2%2FMSYS2-packages%2Fissues%2F1943&data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637258458551804597&sdata=9Othhu3kprUrr7PcweU%2BXyj3Srqb47nK4vLNhgBI%2FlQ%3D&reserved=0) 
> but I think Cygwin is the right place to file this.
>  >
>  > Relevant prior works:
>  >
>  > * Python 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fcommit%2Fdf2d4a6f3d5da2839c4fc11d31511c8e028daf2c&data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637258458551804597&sdata=k6HtZ2Sl51OgudNjdbdmhcC12c6FTMM8%2F%2BoEv8gNlN0%3D&reserved=0
>  > * libuv 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibuv%2Flibuv%2Fcommit%2Fe7ebae26247d2fee0a04547eb7f9aa8f78d4a642&data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637258458551804597&sdata=ulo1a%2Fy4iwjUK6BRAAi88VEMrXNlU8fIxxLptA6Y3uU%3D&reserved=0
>  > * PowerShell 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPowerShell%2Fpull%2F10331&data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637258458551804597&sdata=OhuYhKsNYkfCEB3trhdm6QF1wdzAhGdqRRTQi8V350w%3D&reserved=0
>  >
>  > Thanks,
>  >
>  > -Kagami
>  >
> 
> Not clear why you expect that a Windows specific tag as
> IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
> 
> Moreover all the documentation from MS seems
> 
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-fscc%2Fc8e77b37-3909-4fe6-a4ea-2b9d423b1ee4&data=02%7C01%7C%7Ca89ae101a11349ad859008d7ff3113b0%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637258458551814592&sdata=IdYc3OG4UdvTo2IJeSmwsSvaqcAFdsM3ZmhV2RicMqA%3D&reserved=0
> 
> that seems a bit short to help third party in properly using it.
> 
> Regards
> Marco
> 
> 
> PS: Python 3.8 is available as Cygwin binary
> 


have you tested

"cygstart 
/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe 
  " ?


Regards
Marco

RE: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Kagami Rosylight]

From: Marco Atzeri
> `Reply always with mailing list in copy, please
> and bottom posting as standard
>
> On 23.05.2020 18:34, Kagami Rosylight wrote:
> > Hi Marco,
> >
> > >Not clear why you expect that a Windows specific tag as
> > IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
> >
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fgit%2F%3Fp%3Dnewlib-cygwin.git%3Ba%3Dblob%3Bf%3Dwinsup%2Fcygwin%2Fpath.cc%3Bh%3D36aa8278fd8495bdfe5ec82b8c36d7d3d7881ebb%3Bhb%3Drefs%2Fheads%2Fmaster%23l2473&data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259096391494659&sdata=Llf8pBA7JBtDEThlvynB7Di1E71xjJnLVUJsEI1N6u8%3D&reserved=0
> >
> >
> > Because Cygwin already supports common reparse points (such as symlinks)
> > and APPEXECLINK is also a common one used by Microsoft Store. This issue
> > causes some CLI tools depending on MSYS2 (which again on Cygwin) to fail
> > calling system Python executable.
> >
> > > that seems a bit short to help third party in properly using it.
> >
> > Good point, and that’s why I only could provide the prior works.
> > REPARSE_DATA_BUFFER_APPEXECLINK in the PowerShell patch shows how the
> > structure look like, but this definitely needs an official
> > documentation. I don’t think it’s a strict blocker given that there are
> > public working patches, though.
> >
> > -Kagami
> >
> > *From: *Marco Atzeri
> > *Sent: *Saturday, 23 May 2020 5:50 PM
> > *To: *cygwin@cygwin.com , saschanaz@outlook.com
> > *Subject: *Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK
> >
> > On 23.05.2020 17:09, Kagami Rosylight via Cygwin wrote:
> > > Hi Cygwin community,
> > >
> > > I found that Cygwin can’t run UWP based CLI tools, as they expose
> > their executables as reparse points with the tag
> > IO_REPARSE_TAG_APPEXECLINK which Cygwin does not support.
> > >
> > > Way to reproduce this issue on Cygwin:
> > >
> > > 1. Install Python from Microsoft Store:
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.microsoft.com%2Fen-us%2Fp%2Fpython-38%2F9mssztt1n39l&data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259096391494659&sdata=tJ4DeDmHrHFYPrXIDzLiXZ6vQivQbZVV703SfOqMT%2BM%3D&reserved=0
> > (assuming you don’t already have python3.8 on your PATH.)
> > > 2. Try running `python3.8` on Cygwin. It will say
> > “/cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8:
> > Permission denied”
> > > 3. Check it’s real path by `get-childitem -path
> > C:/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe` on
> > PowerShell. It’s `C:\Program
> > Files\WindowsApps\PythonSoftwareFoundation.Python.3.8_3.8.1008.0_x64__qbz5n2kfra8p0\python3.8.exe`.
> > > 4. Try running python again with that path. This succeeds.
> > >
> > > I posted this issue on MSYS2 GitHub repo
> > (https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmsys2%2FMSYS2-packages%2Fissues%2F1943&data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259096391494659&sdata=9DVvWYnNcgR26LR7p%2FdX2n7uXI8rnL%2BE1nO7ct9ZBF0%3D&reserved=0)
> > but I think Cygwin is the right place to file this.
> > >
> > > Relevant prior works:
> > >
> > > * Python
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpython%2Fcpython%2Fcommit%2Fdf2d4a6f3d5da2839c4fc11d31511c8e028daf2c&data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259096391494659&sdata=PHB5ChU1IX4gfc7NF3XMJqghyoVBic4CJ5fDP1W7LAM%3D&reserved=0
> > > * libuv
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flibuv%2Flibuv%2Fcommit%2Fe7ebae26247d2fee0a04547eb7f9aa8f78d4a642&data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259096391504645&sdata=rA4UuMyybOHo35N6qPF0OYVxFLk0usYuviUH0NjymlU%3D&reserved=0
> > > * PowerShell
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPowerShell%2Fpull%2F10331&data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259096391504645&sdata=cW19cfgbotWpc1loOfYJHoIIvFh2zdSSPhdbeRnIGnw%3D&reserved=0
> > >
> > > Thanks,
> > >
> > > -Kagami
> > >
> >
> > Not clear why you expect that a Windows specific tag as
> > IO_REPARSE_TAG_APPEXECLINK should be supported on a Posix platform ?
> >
> > Moreover all the documentation from MS seems
> >
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-fscc%2Fc8e77b37-3909-4fe6-a4ea-2b9d423b1ee4&data=02%7C01%7C%7Ca9040b39384d422d0b5808d7ffc595f1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637259096391504645&sdata=EsAOzkEfbTP3RxYcFVsWuGax0s2dh2nf38%2FhfW%2Frre8%3D&reserved=0
> >
> > that seems a bit short to help third party in properly using it.
> >
> > Regards
> > Marco
> >
> >
> > PS: Python 3.8 is available as Cygwin binary
> >
>
>
> have you tested
>
> "cygstart
> /cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe
>   " ?
>
>
> Regards
> Marco
>

That works by opening a new window. MSYS2 doesn’t have it by default and I can’t add conditional cygstart calls everywhere just to workaround this issue, though.

Sorry for not keeping the standard style 😬. Which email client do you use to do the "bottom posting"? I copied the whole body from Outlook to my IDE and added ">" to write this, is this what you are doing? It seems there should be more straightforward way as all mailing list users are using this style.

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Marco Atzeri]

On 24.05.2020 11:51, Kagami Rosylight via Cygwin wrote:
> From: Marco Atzeri
>> `Reply always with mailing list in copy, please
>> and bottom posting as standard
>>

>>
>> have you tested
>>
>> "cygstart
>> /cygdrive/c/Users/Kagami/AppData/Local/Microsoft/WindowsApps/python3.8.exe
>>    " ?
>>
>>
>> Regards
>> Marco
>>
> 
> That works by opening a new window. MSYS2 doesn’t have it by default and I can’t add conditional cygstart calls everywhere just to workaround this issue, though.
> 
> Sorry for not keeping the standard style 😬. Which email client do you use to do the "bottom posting"? I copied the whole body from Outlook to my IDE and added ">" to write this, is this what you are doing? It seems there should be more straightforward way as all mailing list users are using this style.
> --


I am usually using Thunderbird, but it works also with Gmail web 
interface with a bit of patience and after setting for NOT using HTML
mail format.


Regards
Marco

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Adam Dinwoodie]

On Sun, 24 May 2020 at 10:51, Kagami Rosylight via Cygwin wrote:
> <snip>
> Sorry for not keeping the standard style . Which email client do you use to do the "bottom posting"? I copied the whole body from Outlook to my IDE and added ">" to write this, is this what you are doing? It seems there should be more straightforward way as all mailing list users are using this style.

Outlook is singularly bad for letting you use this style of email
reply; I'd go so far as to argue it's primarily responsible for the
shift away from this style of reply that was, for a long time in the
history of the internet, very much the standard form. If you're able
to use some other email client to interact with this mailing list (and
mailing lists for other open source projects, which, IME, mostly also
prefer this sort of reply format) you might find that easier.
Personally, when I do have to use Outlook to interact with a mailing
list, I end up copying the email into Vim, writing my reply there, and
copying it back.

(But even then, Outlook mangled your message something rotten: your
email has a bunch of unnecessary Microsoft-proprietary headers, is
base64 encoded for no good reason, and didn't automatically wrap the
text lines at a sensible line length. Which, to be clear, is me having
a grump about Outlook, not about anything you've done, other than use
an email application that you might reasonably think would be able to
send emails without mangling things so badly.)

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[ASSI]

Adam Dinwoodie writes:
> Outlook is singularly bad for letting you use this style of email
> reply;

True, but you _can_ configure it away from that default, although almost
nobody does it and yes it's not very obvious and needs changes in at
least three different corners of the settings maze.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Cygwin doesn't support IO_REPARSE_TAG_APPEXECLINK

[Brian Inglis]

On 2020-05-24 08:59, ASSI wrote:
> Adam Dinwoodie writes:
>> Outlook is singularly bad for letting you use this style of email
>> reply;
> 
> True, but you _can_ configure it away from that default, although almost
> nobody does it and yes it's not very obvious and needs changes in at
> least three different corners of the settings maze.

Thunderbird is not much better, as you have to find the Button to click, to
define domains to which you only wish to send emails in text, and line length,
which is global, not per-domain, or overridable for one message.

-- 
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 IEC units and prefixes, physical quantities in SI.]