Nodejs + npm, installation de modules sur une partition ntfs

J’ai un problème lors de l’installation des modules npm. NodeJS est installé sur Ubuntu 11.10 en cours d’exécution sur Virtual Box sur l’hôte Windows. Mes fichiers de projet sont sur une partition NTFS (je dois les partager avec Windows). Lorsque j’essaie d’installer un module npm, je reçois une erreur et le module n’est pas installé. J’ai découvert que ce problème se produit lorsque npm essaie de créer des liens symboliques.

Vous ne pouvez probablement pas créer de liens symboliques sur la partition NTFS, lorsque j’installe le module “inside” du système de fichiers Linux, tout fonctionne correctement.

Comment puis-je réparer cela? Je ne veux pas résoudre les dépendances manuellement: /

Essayez ceci – http://ahtik.com/blog/2012/08/16/fixing-your-virtualbox-shared-folder-symlink-error/

Travaille pour moi!

Fondamentalement, vous définissez un paramètre

VBoxManage setextradata YOURVMNAME VBoxInternal2 / SharedFoldersEnableSymlinksCreate / YOURSHAREFOLDERNAME 1

Et puis lancez la machine virtuelle en tant qu’administrateur ….

Les permissions Symlink, ou --no-bin-links ne fonctionnaient pas pour nous. Au lieu de cela, nous avons opté pour déplacer nos node_modules du partage /vagrant . Nous avons créé un lien symbolique de /vagrant/node_modules vers /tmp/node_modules . Vous ne pouvez le faire que si votre node_modules n’est pas en contrôle de version . Vérifiez ceci en premier!

Voir aussi http://kmile.nl/post/73956428426/npm-vagrant-and-symlinks-on-windows

Je suis assez certain que des liens symboliques ne peuvent pas être créés sur le lecteur partagé (“dossier partagé”). Encore plus impossible avec une machine hôte Windows et un invité Linux.

Les machines hôtes ne connaissent pas le système de fichiers des invités . Une machine invité est une boîte noire pour l’hôte. Vous ne pouvez pas dire à l’hôte “Eh bien, cela lie à /etc/... lorsque l’hôte ne sait pas où cela /etc est :).

Donc en bref: malheureusement non.


Plus en détail:

Je serais vraiment heureux si je me trompe! C’est une douleur majeure dans mon processus de développement.

J’ai essayé tellement d’options. Par défaut, le système de fichiers utilisé par les “dossiers partagés” est vboxsf , quelque chose qui n’est pas le même que samba (protocole de partage réseau par défaut pour Windows):

  1. J’ai essayé d’utiliser le partage réseau Windows natif , puis de monter le lecteur réseau dans l’invité, car l’invité et l’hôte se trouvent sur le même réseau. Le problème était toujours là .
  2. J’ai essayé d’ exécuter un serveur NFS sur Windows (Hanewin NFS Server) avec SFU / SUA (Windows Services for UNIX), mais cela pose des problèmes avec les verrous GIT . Probablement d’autres problèmes aussi – c’était il y a un moment et je ne me souviens pas clairement
  3. J’ai essayé l’inverse: partager un répertoire sur la machine virtuelle avec Windows. Mais c’est stupide car tous les fichiers seront sur la boîte virtuelle et il est vraiment lent d’accéder aux fenêtres
  4. J’étais stupide et je pensais bien ” monter un lecteur virtuel sur Windows et Linux” – n’essayez pas ceci, corrompt le disque virtuel. Quelque chose que j’aurais dû savoir.

Il pourrait y avoir un protocole de partage de réseau autre que samba et nfs qui copiera peut-être les fichiers chaque fois qu’une tentative de “lien symbolique” sera tentée? Je ne sais pas vraiment.

Cependant, je n’en ai pas encore trouvé et le “locking” semble être une tâche du système de fichiers lui-même, donc je doute qu’un protocole réseau (à moins d’avoir un registre dédié aux verrous) puisse le faire.

Pour ceux qui ont encore ce problème après avoir essayé npm install --no-bin-links .

Je n’ai pas réussi à faire fonctionner l’une des solutions ci-dessus lorsque je suis tombé sur un problème similaire en npm install sur une boîte Vagrant Laravel Homestead sur un hôte Windows 7 à l’aide de VirtualBox. La boîte invité contient un répertoire mappé vers le système de fichiers Windows.

Le problème était à l’origine de divers messages d’erreur et de l’installation du package ayant échoué. Celui qui est le plus pertinent pour la question était npm ERR! UNKNOWN, symlink '' npm ERR! UNKNOWN, symlink '' .

Pour résoudre ce problème, j’ai réussi à exécuter npm install sur la ligne de commande Git bash sous Windows plutôt que sur Linux invité.

Pour ce faire, vous devez installer Git pour Windows et NodeJS (tous deux dans votre boîte Windows).

par exemple

  1. Installez Chocolatey https://chocolatey.org/
  2. choco install nodejs.install
  3. choco install git.install
  4. Exécutez C:\Program Files (x86)\Git\Git Bash.vbs
  5. Dans la ligne de commande Git Bash, changez le répertoire à l’emplacement de votre fichier package.json, par exemple cd /c/projects/projectname
  6. Exécutez npm install

Tout semble s’installer avec succès.

Si vous n’utilisez pas de modules natifs (compilés à partir de C / C ++), vous pouvez simplement utiliser npm sur votre machine virtuelle Ubuntu et copier le dossier node_modules sur votre lecteur Windows.

Jeu de comportement fsutil SymlinkEvaluation L2L: 1 R2R: 1 L2R: 1 R2L: 1

cette commande active les liens symboliques sur Windows. pour une meilleure explication des commandes cryptiques à la fin de la visite: Comment surmonter le “Le lien symbolique ne peut pas être suivi car son type est désactivé”. erreur lors de l’obtention de la cible d’un lien symbolique sur Server 2008?

En résumé

Les codes de comportement de l’ensemble de comportements fsutil SymlinkEvaluation – à savoir L2L, L2R, R2L et R2R – sont les suivants:

L signifie “Local”, et R pour “Remote” (qui aurait du thunk?) FIRST L ou R – avant le 2 – se réfère à l’emplacement du lien lui-même (par opposition à sa cible) par rapport à la machine ACCÉDER au lien Le SECOND L ou R – après le 2 – fait référence à l’emplacement de la cible du lien par rapport à la machine où se trouve le LINK lui-même.