public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Change in logical link behaviour
Date: Tue, 03 Mar 2020 14:19:00 -0000	[thread overview]
Message-ID: <20200303133925.GA4045@calimero.vinschen.de> (raw)
In-Reply-To: <d04228d9-eff9-6dd4-6cfc-80b24bc8fa3b@emrich-ebersheim.de>

[-- Attachment #1: Type: text/plain, Size: 5080 bytes --]

On Mar  3 14:17, Rainer Emrich wrote:
> Dear Corinna,
> 
> Am 02.03.2020 um 17:48 schrieb Corinna Vinschen:
> > On Feb 29 14:10, Rainer Emrich wrote:
> >> I try to reliably determine if native Windows symlink are working for a
> >> current cygwin environment in a shell script.
> >> [...]
> >> On cygwin 3.1.4 I get:
> >>
> >>
> >>     Directory: D:\cygwin\home\rainer\temp
> >>
> >>
> >> Mode                LastWriteTime         Length Name
> >> ----                -------------         ------ ----
> >> d----        29.02.2020     13:58                asdfgh-1
> >>
> >> So now there is no indication that this is a link. Is this new behaviour
> >> intended or a bug?
> >>
> >> I did not try on Windows 10, I'm still on windows 7.
> > 
> > I can't reproduce this behaviour.  Keep in mind that, [bla]
> I know all the implications. I have to test in an unknown cygwin
> environment if it is possible to set native symlinks.
> > 
> > So, on Windows 7 in an elevated shell:
> > 
> >   # id -G | grep -Eq '\<544\>' && echo elevated || echo non-elevated
> >   elevated
> >   # uname -a
> >   CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
> >   # mkdir qwe
> >   # cd qwe
> >   # export CYGWIN="winsymlinks:nativestrict"
> >   # touch foo
> >   # ln -s foo bar
> >   # cmd /c dir /a
> >    Volume in drive C has no label.
> >    Volume Serial Number is A8E0-A24E
> > 
> >    Directory of C:\cygwin64\home\corinna\qwe
> > 
> >   2020-03-02  17:31    <DIR>          .
> >   2020-03-02  17:31    <DIR>          ..
> >   2020-03-02  17:31    <SYMLINK>      bar [foo]
> >   2020-03-02  17:31                 0 foo
> >                  2 File(s)              0 bytes
> > 		 2 Dir(s)   7.907.352.576 bytes free
> > 
> Yes, this is the same for me, but if you use the powershell
> 
> # powershell "& {Get-Item -Path bar | Select-Object}"
> 
> on cygwin 3.0.7 you get
> 
>     Directory: D:\cygwin\home\rainer\temp
> 
> Mode                LastWriteTime         Length Name
> ----                -------------         ------ ----
> -a---l       03.03.2020     14:09              0 bar
> 
> and on cygwin 3.1.4 you get
> 
>     Directory: D:\cygwin\home\rainer\temp
> 
> Mode                LastWriteTime         Length Name
> ----                -------------         ------ ----
> -a---        03.03.2020     14:09              0 bar
> 
> 
> The only difference is the used cygwin version. So, I don't understand
> what has changed.

Nothing has changed in terms of symlink handling.  Are you saying that
`cmd /c dir /a' shows

  2020-03-03  14:21    <SYMLINK>      bar [foo]

but powershell shows

  -a---        03.03.2020     14:21              0 bar

for the same file?  That would be most puzzeling but certainly outside
of Cygwin's control.

So I created a symlink again on W7 with Cygwin 3.1.4 and `export
CYGWIN=winsymlinks:nativestrict', and tried with cmd *and* powershell
(which I usually don't touch) and I see

  # uname -a
  CYGWIN_NT-6.1 vmbert764 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
  # setenv CYGWIN winsymlinks:nativestrict
  # ln -s foo bar
  # cmd /c dir /a bar
   Volume in drive C has no label.
   Volume Serial Number is A8E0-A24E

   Directory of C:\cygwin64\home\corinna\qwe

  03.03.2020  14:30    <SYMLINK>      bar [foo]
		 1 File(s)              0 bytes
		 0 Dir(s)   7.929.241.600 bytes free
  # powershell "& {Get-Item -Path bar | Select-Object}"


      Directory: C:\cygwin64\home\corinna\qwe


  Mode                LastWriteTime     Length Name
  ----                -------------     ------ ----
  -a---        03.03.2020     14:30          0 bar

Aha!  So powershell does not show the 'l'.

Let's try the same on Windows 10:

  # uname.ORIG -a
  CYGWIN_NT-10.0 vmbert10 3.1.5(0.340/5/3) 2020-03-02 18:46 x86_64 Cygwin
  # setenv CYGWIN winsymlinks:nativestrict
  # ln -s foo bar
  # cmd /c dir /a bar
   Volume in drive C has no label.
   Volume Serial Number is C65C-2A36

   Directory of C:\cygwin64\home\corinna\tmp

  2020-03-03  14:33    <SYMLINK>      bar [foo]
		 1 File(s)              0 bytes
		 0 Dir(s)  23,112,925,184 bytes free
  # powershell "& {Get-Item -Path bar | Select-Object}"


      Directory: C:\cygwin64\home\corinna\tmp


  Mode                LastWriteTime         Length Name
  ----                -------------         ------ ----
  -a---l       2020-03-03     14:33              0 bar

Aha!  powershell shows the 'l'.  Also, notice how the number of
mode bits seem to be only 5 on Windows 7:

  -a---
  ^^^^^
  12345

but *6* on Windows 10:

  -a---l
  ^^^^^^
  123456

On Windows 10 it shows 6 mode bits for non-symlinks as well, so the 'l'
mode is not just missing on Windows 7 in this specific case, but a
generic difference.  From my POV, this is just a shortcoming of W7
powershell.  Keep in mind that the output of powershell has nothing to
do with Cygwin itself.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2020-03-03 13:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-29 13:11 Rainer Emrich
2020-03-01  2:05 ` Andrey Repin
2020-03-01 17:01   ` Rainer Emrich
2020-03-02 16:49 ` Corinna Vinschen
2020-03-03 13:17   ` Rainer Emrich
2020-03-03 13:39     ` Rainer Emrich
2020-03-03 14:19     ` Corinna Vinschen [this message]
2020-03-03 14:27       ` Rainer Emrich
2020-03-03 14:31         ` Rainer Emrich
2020-03-03 16:05         ` Corinna Vinschen
2020-03-03 16:32           ` Corinna Vinschen
2020-03-03 16:41             ` Rainer Emrich
2020-03-03 16:46               ` Rainer Emrich
2020-03-03 17:34               ` Corinna Vinschen
2020-03-03 21:43                 ` Rainer Emrich
2020-03-04 19:45               ` Andrey Repin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200303133925.GA4045@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).