0
votes

Pourquoi certains symboles de Cygwin ne sont-ils pas visibles d'une session CMD.EXE

Résumé: strong>

dans la version la plus récente (202020) de Cygwin 64 bits, les symboles dans le / bin / code> et / Les annuaires LIB CODE> ont des caractéristiques déroutantes et semblent différer de l'un des différents autres symboles documentés. Les questions sont: p>

  1. Pourquoi sont-ils cachés de cmd.exe, mais visible ailleurs, contrairement à AUTRES TYPES SYMLINK P> li>

  2. est-il possible de créer des liens symboliques avec des fonctionnalités identiques? Si oui, comment? p> li> ol>

    tl; dr fort> Voir la réponse de @ Matzeri: l'attribut système est défini sur / bin / awk code>, ce qui le rend invisible aux sessions cmd.exe. P>

    Les symboles de symboles ci-dessous / bin code > et / lib code> semblent être l'un des deux types de "symboles de cygwin par défaut" décrites ici: P>

    Les liens sympathiques par défaut créés par Cygwin sont soit spécialement reparse points partagés avec WSL sous Windows 10, ou fichiers unis contenant un Cookie magique suivi du chemin vers lequel les points de liaison. le Le point de repères est utilisé sur NTFS, le fichier ordinaire sur presque tous les autres système de fichiers. Voir Liens symboliques P> BlockQuote>

    Cependant, tous les symboles de symboles ci-dessous / bin code> ont le jeu d'attributs système et la plupart des symboles ci-dessous / lib code> ne font pas. Je ne sais pas comment ai-je pu créer un symbole symbolique avec un cookie magique sur NTFS. P>

    ci-dessous est la version longue de la question forte> p>

    là sont plusieurs types de symboles de symboles sous Cygwin. D'autres questions expliquent leur histoire, décrivent leurs différences et montrer comment les créer, etc. Par exemple: p>

    Vérifiez la différence de type Symlink en Cygwin P>

    Voici une discussion sur une partie de l'histoire et des problèmes liés aux liens symboliques sous Windows: P >

    Symlinks sur les annuaires Windows montés ne sont pas compatibles avec Native P >

    Comme décrit, il existe des raccourcis, des points de jonction et des liens symboles, tous visibles d'une session CMD.exe, comme illustré. P>

    Cependant, sous mon installation de Cygwin 64 bits, est un autre type que je ne trouve aucune explication pour. Un nombre d'entre eux apparaissent ci-dessous / bin code>, / lib code>, et peut-être d'autres endroits. La principale caractéristique qui les distingue des 3 autres est qu'ils ne sont pas visibles d'une session CMD.exe. P>

    Voici un exemple: Si j'essaie de répertorier "Awk" via cmd.exe à partir du répertoire / bin, le fichier semble ne pas exister: p> xxx pré>

    Voici ce qu'il semble ls Code>: P>

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


2 commentaires

awk est un fichier broit avec un attribut système Windows, et est donc masqué par défaut. Utilisez dir / a pour afficher des fichiers cachés.


Ceci est un lien symbolique spécifique à cygwin. Dans Windows, il s'agit simplement d'un fichier texte brut contenant ! gawk.exe \ 0


3 Réponses :


1
votes

Cygwin est beaucoup, beaucoup plus vieux que la prise en charge des NTFS pour les liens symboliques. Par conséquent, Cygwin a sa propre mise en œuvre de liens symboliques, qui est essentiellement juste un fichier texte contenant le texte ! gawk.exe et est terminé par un caractère ASCII Nul .


1 commentaires

Il y a en fait un point d'exclamation que le premier caractère: "! gawk.exe"



1
votes

La raison pour laquelle les liens ne sont pas visibles est due à leur attribut de fichier

S = système ne sont pas visibles dans cmd par DOS / Windows Design,
De CMD, désolé en allemand, nous avons: xxx


0 commentaires

0
votes

J'utilise GoodSync pour synchroniser le volume où Cygwin est installé sur un NAS. Ceci est déclenché par des changements et est censé fonctionner en arrière-plan. Depuis quelque temps (je ne peux pas dire quand précisément), le programme d'installation de Cygwin semble créer des liens natifs Windows par défaut (dans de nombreux cas, pas tous). Définition d'une variable système Cygwin à Winsymlinks: LNK ne semble pas aider. La configuration dans le profil Bash à l'échelle du système ne résout pas également le problème.

Toutefois, comme ces liens ne peuvent pas être résolus correctement à partir d'une application Windows (un lien / etc. / alternatives / 2to3 points sur /usr/bin/2to3-3.8 ), les lire de Goodsync échouera - mis à part le fait qu'ils ne peuvent être sauvegardés. L'option "ignorer" sur des liaisons symboliques dans GoodSync n'a pas l'effet souhaité (peut-être que seules les véritables liens symboliques et ne repère pas les points - j'ai déjà signalé que Bug déjà).

Alors, ma solution est donc Pour surveiller de telles erreurs, puis exécutez ce script avec une liste de chemins impliqués pour corriger les liens vers les fichiers anciens de style cygwin. xxx

pour une initiale Scan, j'ai exécuté un Trouver / -type L -Print sur l'ensemble de l'installation Cygwin, a filtré ces chemins où un fichier .LNK du même nom existait et fixe le reste. < P> Dans WSL, les mêmes problèmes existent - sauf qu'il n'y a pas de solution simple. Les liens symboliques sont des liens natifs Windows et ne peuvent pas être lus s'ils pointent sur des chemins de style UNIX. Il n'y a pas de représentation alternative sauf le recours à des chemins cibles relatifs. Ceux (mai) ont une chance d'être interprété correctement aussi par Windows.

Création de sauvegardes de fichier 1: 1 des systèmes de fichiers avec de tels liens restera un défi.


0 commentaires