为什么从cmd.exe会话中看不到某些cygwin符号链接 [英] why are some cygwin symlinks not visible from a cmd.exe session

查看：73 发布时间：2021/2/14 19:44:57 scala jvm cygwin symlink

本文介绍了为什么从cmd.exe会话中看不到某些cygwin符号链接的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

摘要:

在最新版本(2020年9月)的64位cygwin中，/bin/和/lib目录中的符号链接具有令人困惑的功能，并且似乎与任何其他已记录的符号链接都不相同.问题是:

In the most recent (Sept. 2020) version of 64-bit cygwin, the symlinks in the /bin/ and /lib directories have puzzling features, and seem to differ from any of the various other documented symlinks. The questions are:

为什么它们对CMD.EXE隐藏，但在其他地方可见，不像其他符号链接类型

why are they hidden from CMD.EXE, but visible elsewhere, unlike other symlink types

是否可以创建具有相同功能的符号链接?如果可以，怎么办?

is it possible to create symlinks with identical features? if so, how?

TL; DR 请参阅@matzeri的答案:SYSTEM属性在/bin/awk上设置，使其对CMD.EXE会话不可见.

TL;DR See @matzeri's answer: the SYSTEM attribute is set on /bin/awk, making it invisible to CMD.EXE sessions.

在/bin和/lib下的符号链接似乎是两种类型的默认cygwin符号链接"之一.在这里描述:

The symlinks below /bin and /lib seem to be one of the two types of "default cygwin symlinks" described here:

Cygwin创建的默认符号链接是特殊解析的 Windows 10上与WSL共享的点，或包含魔术cookie，然后是链接指向的路径.这在NTFS上使用重解析点，在几乎所有其他文件上使用纯文件文件系统. 参见符号链接

The default symlinks created by Cygwin are either special reparse points shared with WSL on Windows 10, or plain files containing a magic cookie followed by the path to which the link points. The reparse point is used on NTFS, the plain file on almost any other filesystem. see symbolic links

但是，/bin下的所有符号链接均设置了SYSTEM属性，而/lib下的大多数符号链接均未设置.我不知道如何在NTFS上使用魔术cookie创建符号链接.

However, all of the symlinks below /bin have the SYSTEM attribute set, and most of the symlinks below /lib don't. I don't know how was I able to create a symlink with a magic cookie on NTFS.

下面是问题的长版

cygwin下有多种类型的符号链接.其他问题可以解释它们的历史，描述它们的差异以及显示如何创建它们，等等.例如:

There are multiple types of symlinks under cygwin. Other questions explain their history, describe their differences, and show how to create them, etc. For example:

检查cygwin中符号链接类型的差异

这里是有关Windows符号链接的一些历史和问题的讨论:

Here's a discussion of some of the history and problems with symlinks on windows:

已安装的Windows目录上的符号链接与本机不兼容

如前所述，有一些快捷方式，连接点和符号链接，所有这些都可以从CMD.EXE会话中看到，如所示.

As described, there are shortcuts, junction points, and symlinks, all of which are visible from a CMD.EXE session, as demonstrated.

但是，在我的64位cygwin安装中，还有另一种我找不到任何解释的类型.其中许多出现在/bin，/lib以及其他地方.它们与其他3个区别的主要特征是，它们在CMD.EXE会话中不可见.

However, under my 64-bit cygwin installation, there is another type that I can't find any explanation for. A number of them appear below /bin, /lib, and perhaps other places. The main characteristic that distinguishes them from the other 3 is that they aren't visible from a CMD.EXE session.

这里是一个例子: 如果我尝试通过/bin目录中的CMD.EXE列出"awk"，则该文件似乎不存在:

Here's one example: If I attempt to list 'awk' via CMD.EXE from the /bin directory, the file seems to not exist:

$ cd /bin

$ cmd.exe /c dir awk

 Volume in drive C is opt
 Volume Serial Number is D0C8-EA58

 Directory of C:\cygwin64\bin

File Not Found

这是ls的外观:

$ ls -l awk
lrwxrwxrwx 1 philwalk None 8 May 14 12:26 awk -> gawk.exe

但是，根据我的经验，大多数符号链接在CMD.EXE会话中可见.让我们创建一个用于测试的符号链接:

But most symlinks, in my experience, ARE visible from a CMD.EXE session. Let's create a symlink for testing:

$ CYGWIN=winsymlinks:nativestrict # make sure we don't create an old-style symlink
$ ln -s `which ls.exe` ls-link
$ cmd.exe /c dir ls-link
 Volume in drive C is opt
 Volume Serial Number is D0C8-EA58

 Directory of C:\opt\ue

2020-09-03  13:12    <SYMLINK>      ls-link [C:\cygwin64\bin\ls.exe]
               1 File(s)              0 bytes
               0 Dir(s)  295,290,556,416 bytes free

这表明CMD.EXE可以看到这种类型的符号链接.

This shows that CMD.EXE can see this type of symlink.

似乎所有符号链接都可以像这样被取消引用:

It appears that all symlinks can be dereferenced like this:

$ cygpath -w `which awk`
C:\cygwin64\bin\gawk.exe

那么基于Windows的程序可以取消对它们的引用吗?它可以看到他们吗?因为它们对CMD.EXE不可见，所以我猜想它们对任何其他Windows(即非Cygwin)程序都不可见.

So can a windows-based program dereference them? Can it see them at all? Because they aren't visible to CMD.EXE, I would have guessed that they aren't visible to any other windows (i.e., non-cygwin) program.

这是一个Scala脚本deref.sc，它将测试以下问题:

Here's a scala script, deref.sc, that will test these questions:

#!/usr/bin/env scala

import java.nio.file._

for( posixPath <- args ){
  val cyg = cygpath(posixPath)
  val windows = Paths.get(posixPath)
  val exists = Files.exists(windows)
  printf("file path [%s]\n",posixPath )
  printf("cygpath   [%s]\n",cyg)
  printf("windows   [%s]\n",windows)
  if( exists ){
    printf("exists  [%s] # visible to jvm-based programs\n",exists)
  } else {
    printf("exists  [%s] # NOT visible to jvm-based programs\n",exists)
  }
  val realpath = if( exists ){
    if( Files.isSymbolicLink(windows) ){
      Files.readSymbolicLink(windows)
    } else {
      windows.toRealPath()
    }
  }
  printf("real windows [%s]\n",realpath)
  printf("\n")
}
def cygpath(posixPath:String) = {
  import scala.sys.process._
  Seq("cygpath.exe","-m",posixPath).lazyLines_!.mkString("")
}

这是deref.sc的输出，应用于/bin/awk和./ls-link. (我们必须传递Windows可见的/bin/awk版本)

Here's the output from deref.sc as applied to /bin/awk and to ./ls-link. (we have to pass the windows-visible version of /bin/awk)

$ deref.sc ls-link
cygpath   [ls-link]
windows   [.\ls-link]
exists  [true] # visible to jvm-based programs
real windows [C:\cygwin64\bin\ls.exe]
$ cd /bin

$ deref.sc awk
file path [awk]
cygpath   [C:/cygwin64/bin/gawk.exe]
windows   [awk]
exists  [true] # visible to jvm-based programs
real windows [C:\cygwin64\bin\awk]

因此，这表明，尽管某些Windows程序(例如CMD.EXE)看不到c:/cygwin64/bin/awk，但其他Windows程序(例如基于jvm的程序)可以看到！

So this shows that, although some windows programs (such as CMD.EXE) cannot see c:/cygwin64/bin/awk, others (such as jvm-based programs) can!

我最初的问题是基于一个错误的假设，即Windows程序无法看到这些新的符号链接，并且由于这是不正确的，因此剩余的问题是:

My original question was based on the mistaken assumption that windows programs are not able to see these new symlinks, and since that isn't correct, the residual question is:

这些新的符号链接是什么，以及它们是如何创建的?它们真的不同吗，或者这可能是权限的副作用?以管理员身份运行CMD.EXE似乎没有任何作用.

What are these new symlinks, and how are they created? Are they really different, or is this perhaps a side-effect of permissions? Running CMD.EXE as administrator seems to make no difference.

我验证了c:/cygwin64/bin/awk在WSL会话中也是可见的，尽管考虑到jvm可以看到它们，这也并不令人惊讶.

I verified that c:/cygwin64/bin/awk is also visible from a WSL session, although that's not so surprising given that the jvm can see them.

更新:看来，尽管/bin/awk对我们的程序是可见的，但java.nio.file.Files.isSymbolicLink()并不将其视为符号链接.它的内容由字符串"!<symlink>gawk.exe"组成，因此在Windows提供本机符号链接之前，它似乎是符号链接的早期cygwin实现.

UPDATE: it seems that, although /bin/awk is visible to our program, it isn't considered to be a symbolic link by java.nio.file.Files.isSymbolicLink(). Its contents consist of the string "!<symlink>gawk.exe", so it seems to be an early cygwin implementation of symlinks, before windows provided native symlinks.

除了从CMD.EXE中不可见之外，其他均不明显.

It's unremarkable except for being invisible from CMD.EXE.

为什么从cmd.exe会话中看不到某些cygwin符号链接 [英] why are some cygwin symlinks not visible from a cmd.exe session

问题描述

推荐答案

相关文章

其他开发最新文章

热门教程

热门工具

登录关闭

为什么从cmd.exe会话中看不到某些cygwin符号链接 [英] why are some cygwin symlinks not visible from a cmd.exe session

问题描述

推荐答案

相关文章

其他开发最新文章

热门教程

热门工具

登录 关闭

登录关闭