Linux? - Page 229

Brunni > c'est du Ruby, donc ça devrait fonctionner sans souci sur Mac.

Ruby?

:/

Attends, un langage qui porte le nom d'un bijou coloré, c'est parfait pour un soft comme ça !

Hummmm mouai... non ;p

Quand je suis sous ma partition Linux, je regrette Windows pour accéder à la plupart de mes jeux PC, certains softs...
Quand je suis sous ma partition Windows, je regrette tous mes outils de développement, la souplesse pour utiliser ssh, etc.

...
Le bash Ubuntu sous Windows 10, c'est la puissance <3 très fonctionnel et peut même lancer des applis graphiques utilisant X.

mais ne gère ni samba ni périphériques usb (le dernier est un peu la misère pour du dev embarqué)

en plus question

ouvrez votre bash windows
créez un fichier quelconque dans le dossier home
il apparait dans c:\utilisateurs\vous\AppData\Local\Lxss\rootfs\home\vous (ca reste caché, faut le taper dans la barre d'adresse)

c'est cool

maintenant créez y un fichier depuis windows, dans ce rootfs (/home/vous)

il n'apparait pas dans bash. nada. même en réouvrant une session.

ou alors vous me dites comment vous faites.

et y'a aussi des bugs quand on fait des liens symboliques depuis le rootfs vers des dossiers de /mnt/c , du coup il est totalement impossible d'utiliser (a mon taf) un repo svn qui est hébergé sur un share samba, ni même utiliser une working copy partagée entre win et bash.
-soit elle est dans /mnt/c et les symlinks chient
-soit on la checkout dans le rootfs et elle apparait pas
-cifs n'est pas supporté by design donc pas de shares samba accessibles

donc on a une vm virtualbox avec un vboxshare qui fonctionne mal, donc on a du faire un script de build qui commence par rsyncer le vboxshare dans le filesystem de la vm. pratique.

En même temps il me semble que c'est toujours en bêta, et Microsoft a besoin de votre aide pour savoir ce qui ne marche pas → bug report

Pareil que Meowcate ici. Ca marche tout à fait correctement parce que j'ai pas des besoins squalylesques.

Certes, pour l'heure mes besoins ont été limité.

... maintenant que j'y pense, c'est bien un réflexe Linux que j'ai eu : chercher comment faire tourner le bash Windows, afin de lancer ssh, ça m'a pris un moment d'installation, alors que j'aurais pu dl directement un programme Windows pour faire cela.
Mais on ne se sent jamais aussi bien qu'aux commandes d'un terminal :3

Putty ftw

godzil: ils sont déja au courant.

C'est dommage que le home ne soit pas le userprofile et qu'il n'y ait pas une gestion parallèle et compatible des droits (on arrive très bien à avoir ça dans des environnements mixtes Linux/Windows avec des montages automatiques, surtout depuis que Linux gère les ACL).

absolument

le plus choquant est que les fichiers faits sous win n'apparaissent pas dans bash

ils doivent utiliser des streams NTFS pour stocker les droits linux.

c'est un peu con parce que SFU y arrivait bien à l'époque

issue https://github.com/Microsoft/BashOnWindows/issues/552
explication https://blogs.msdn.microsoft.com/wsl/2016/06/15/wsl-file-system-support/

Inodes in Linux have a number of attributes which don’t exist in Windows, including their owner and group, the file mode, and others. These attributes are stored in NTFS Extended Attributes associated with the files on disk. The following information is stored in the Extended Attributes:

Mode: this includes the file type (regular, symlink, FIFO, etc.) and the permission bits for the file.
Owner: the user ID and group ID of the Linux user and group that own the file.
Device ID: for device files, the device major and minor number of the device. Note that WSL currently does not allow users to create device files on VolFs.
File times: the file accessed, modified and changed times on Linux use a different format and granularity than on Windows, so these are also stored in the EAs.

In addition, if a file has any file capabilities, these are stored in an alternate data stream for the file. Note that WSL currently does not allow users to modify file capabilities for a file.

The remaining inode attributes, such as inode number and file size, are derived from information kept by NTFS.
Interoperability with Windows

While VolFs files are stored in regular files on Windows in the directories mentioned above, interoperability with Windows is not supported. If a new file is added to one of these directories from Windows, it lacks the EAs needed by VolFs, so VolFs doesn’t know what to do with the file and simply ignores it. Many editors will also strip the EAs when saving an existing file, again making the file unusable in WSL.

Additionally, since VFS caches directory entries, any modifications to those directories that are made from Windows while WSL is running may not be accurately reflected.

C'est nul. ils pourraient mieux synchroniser les fichiers sans EA plutot que les ignorer.

ce problème la est chiant aussi.
https://github.com/Microsoft/BashOnWindows/issues/729

Mais les synchroniser comment ? Avec quels droits, user et group ? Quelles dates ?
Tes scripts qui tiendraient compte d'un seul de xes éléments pourraient faire des dégâts, tout en paraissant fonctionner normalement, ce qui n'est clairement pas ce que tu veux.
Ils ont fait un choix, discutable certes, mais safe pour les données.

Bof, c'est très bien géré quand tu montes un dossier avec cifs (depuis un serveur Windows, même pas depuis du Samba) : il y a des notions de propriétaire dans le monde MS qui pourraient très bien servir à la fois pour le user et le groupe unix.
Sinon, la possibilité de faire comme avec Samba : un paramétrage à faire pour déterminer que faire par défaut lorsqu'il y a une ambiguïté.

Après, ça ressemble quand-même à une limitation du driver NTFS côté Windows (par choix ?) qui ne renseigne pas ces informations alors qu'il pourrait (en utilisant les informations d'utilisateur Unix au moment de la création du fichier, par exemple).

Sinon, un partage de type webdav ne permettrait pas de contourner le problème ?

Nil: non c'est different, Samba ne simule pas un filesystem, contrairement a ce que fait Microsoft la.

Nil (./6857) :
Après, ça ressemble quand-même à une limitation du driver NTFS côté Windows (par choix ?) qui ne renseigne pas ces informations alors qu'il pourrait (en utilisant les informations d'utilisateur Unix au moment de la création du fichier, par exemple)

Tu veux dire, on est dans le répertoire home de l'utilisateur machin, donc on crée le fichier en rw pour l'utilisateur machin ?
Ca demanderait :
- de définir des permissions (donc rw, par exemple)
- de hacker linux pour aller connaitre le couple uid/gid

En plus d'être un hack bien crade, c'est complètement arbitraire, je vois pas comment tu peux deviner des permissions par exemple...

Ca me semble très sage de ne rien faire, plutôt que de faire quelque chose pour faire croire que tout va bien, alors qu'on a potentiellement fait une grosse connerie.

Je sais bien, mais ce que je veux dire c'est qu'il y a possibilité d'interpréter les informations de droits sur les fichiers Windows pour un environnement Unix sans qu'il y ait de risque de corruption ou de mauvaise compréhension, parce que ça se fait déjà dans un autre contexte.

Il pourrais y avoir un outil pour editer ces infos.

Nil: tu oublie que le Linux pseudovirtualisé fonctionne independement de Windows. Sous Samba, soit tu utilse un compte generique, soit tu te log avec un compte local, mais c'est le serveru SMB qui gere reelement et pas Samba. C'est cote serveur et non client que ce genre de chsoes sont géré.

La pour que ca marche il faudrait que le linux utilise les comptes windows, ce qu'ils n'ont pas fait, on pourrais peut etre faire une table de corerspondance (?) mais ca reste un gros hack crade

Folco (./6860) :

- de définir des permissions (donc rw, par exemple)

Mais ces permissions existent déjà dans l'environnement Windows, pour le propriétaire, du coup en quoi est-ce un problème de poursuivre (comme on le fait naturellement sous Windows comme avec Linux avec les permissions héritées.

- de hacker linux pour aller connaitre le couple uid/gid

Euh tout le système est un hack, à la base ; les fichiers créés sous l'environnement Linux se retrouvent avec des droits NTFS normaux (y compris des droits de propriétaire), probablement parce qu'il y a une API d'abstraction qui permet justement d'aller lire les SID (équivalent des uid/gid) Windows au moment de la création des fichiers dans Linux. Je ne vois absolument aucune contre indication à ce qu'il y ait une API identique (qui interrogerait un service, ou directement le FS de la partie Linux pour lire les informations des utilisateurs) pour récupérer ces informations.

Non les permission Windows, meme si en apparence ressemble, sont assez differentes, voir meme TRES differentes.

Nil (./6864) :
les fichiers créés sous l'environnement Linux se retrouvent avec des droits NTFS normaux (y compris des droits de propriétaire), probablement parce qu'il y a une API d'abstraction qui permet justement d'aller lire les SID (équivalent des uid/gid) Windows au moment de la création des fichiers dans Linux

Pas certain de bien te comprendre : Linux lirait les SID en créant un fichier ?
De ce que j'ai compris, la création d'un fichier par Linux est interceptée par Windows, qui s'occupe classiquement des SID, et stocke la partie purement unix dans les EA.

Nil (./6864) :
Je ne vois absolument aucune contre indication à ce qu'il y ait une API identique (qui interrogerait un service, ou directement le FS de la partie Linux pour lire les informations des utilisateurs) pour récupérer ces informations

Un service de Linux ? Il n'est pas censé tourner tout le temps. Le linux est censé être vanilla, ignorant complètement qu'il est en fait interfacé avec Windows.

Quant à hacker une partition... hum Même si tu retrouves les différents uid/gid, qu'est-ce qui te permettrait de deviner lesquels choisir ? Uniquement l'emplacement où l'on crée le fichier ? AMHA c'est une présomption bien trop forte pour être fiable.

Nil (./6864) :
Euh tout le système est un hack, à la base ; les fichiers créés sous l'environnement Linux se retrouvent avec des droits NTFS normaux

Oui mais non, je veux dire qu'un interface n'est pas un hack, quand même ^^
Quand Linux ouvre un fichier, la couche Windows a recréé un fichier unix de façon totalement transparente, donc les droits Windows du fichier physiquement présent sur le disque dur n'ont pas grande importance.
Ce qui est important, c'est que Linux a la maitrise complète des metadata quand il lit ou écrit un fichier, sans corruption ni hack.

pour info ils FONT DEJA les bonnes choses (guess des droits et proprios) pour leurs montages /mnt/c etc

ils pourraient par exemple IMPORTER les fichiers créés "inconnus" (ceux qui n'ont pas les Extended Atributes requis) et définir des droits par défaut a l'énumération initiale de ces fichiers dans le sous-système linux. par exemple ils savent lire et honorer le bit RDONLY dans les montages /mnt/c le bit x peut être initialement mis a 0 et les proprios a ceux du shell en cours.

quant au fait que le dcache rende ces fichiers invisibles c'est débile, suffit d'invalider le cache quand un fichier créé sous win est détecté.

Non, faut pas déconner, ces problématiques sont gérées correctement depuis des années par SFU, cygwin, MSYS, ils auraient pu s'en inspirer pour faire un truc qui s'intègre bien dans leur portage. même si l'existant leur plait pas, c'est faisable.

Folco (./6866) :
Pas certain de bien te comprendre : Linux lirait les SID en créant un fichier ?
De ce que j'ai compris, la création d'un fichier par Linux est interceptée par Windows, qui s'occupe classiquement des SID, et stocke la partie purement unix dans les EA.

Que ce soit du côté de Windows ou de Linux importe peu : il y a une API qui permet de générer des événements à la volée. Du coup, on peut très bien imaginer la même chose à l'envers, avec un service Unix qui tourne soit en permanence, soit uniquement pendant que le Linux vanilla est en activité avec une synchronisation des métadonnées au démarrage (ce qui me semble un peu lourd s'il y a énormément de nouveau fichiers, mais pas plus que quand il y a une gestion des fichiers hors-ligne au final).

Folco (./6866) :
Quant à hacker une partition... hum Même si tu retrouves les différents uid/gid, qu'est-ce qui te permettrait de deviner lesquels choisir ? Uniquement l'emplacement où l'on crée le fichier ? AMHA c'est une présomption bien trop forte pour être fiable.

Ca, ça peut très bien se faire dans une interface en parallèle où tu poses des équivalences Windows<->Linux (c'est ce que fait Samba en utilisant par défaut l'identifiant comme clé, d'ailleurs).

Hum SFU Cygwin et MSYS ne sont pas de bon exemple je pense.

SFU est juste fournir une API Posix, donc ce n'est pas au niveau binaire. Idem pour Cygwin et MSYS.

"Bash.exe" met en place un "kernel" compatible avec Linux donc un fonctionnement en apparence a l'identique avec les meme syscall, au point qu'un binaire x86_64 ELF fonctionne sans voir la difference entre le kernel linux standard et celui la.

Le sous systeme pour Bash.exe n'est pas au niveua utilisateurs, mais en // avec l'API Win32 et tout le bazard dans le noyal de Windows, ce n'est vraiment pas comparable..

je sais, c'est ce qui permet justement de faire mieux que les autres trucs

sauf qu'il fait pire avec de meilleurs moyens a sa disposition, et ca reste aussi inutilisable que les autres trucs.