J'ai déjà réfléchi à la question :
1) dans le meilleur des mondes, tous les systèmes de fichier supporteraient l'attribut type-mime, et personne ne parlerait d'extension de nom de fichier, donc la configuration par défaut se passerait de commentaire
2) mais il faut pouvoir cohabiter avec des partitions windows, ou utiliser son balladeur mp3. pour ce dernier cas, on touche le fond : on en a encore pour au moins 10 du système de fichier FAT.
Résultat ? Ben soit on attend ad eternam, soit on essaye d'évoluer en restant compatible avec l'ancien.
Alors voici ma vision du problème :
- on admet une bonne fois pour toute que l'arborescence / n'est pas d'un seul tenant, que derrière chaque point de montage se cache des systèmes de fichier différents, certains très basiques., sans perdre de vue qu'il y a quand même des points communs qui font que c'est justement pour ça qu'on peut les réunir dans une grande arborescence.
- quand on cherche à copier/déplacer en restant sur le même type de filesystem (même si c'est une autre partiation), il s'agit bien d'une copie/déplacement standard
- quand on cherche à copier/déplacer d'un ext3 version 2.6 (celui qui supporte les attributs supplémentaires) vers un système de fichier genre FAT (pour donner une idée du niveau), ce ne serait plus une copie qui serait proposé, mais une «exportation», avec un panneau qui s'ouvrirait en disant les modifs qu'il va faire, et après on choisirait entre [laisser tomber|copier avec les modifs proposées|copie brute, on perd des infos au passage mais tant pis].
- inversement de FAT vers ext3, ce ne serait pas une copie, mais une «importation» (noter le message subliminal dans l'utilisation des mots exporter et importer), suivant le même modèle. Dans le cas de l'extension, on la traduirait en type-mime, puis on l'enleverait du nom de fichier
L'avantage : il n'y a pas d'options à choisir pour l'utilisateur lambda, et il n'a qu'à dire «ok» pour l'importation et l'exporation s'il ne veut pas «se prendre la tête». Ça permettrait donc de commencer à exploiter les possibilités nouvelles des fs sans abandonner la compatibilité avec l'ancien, ni devenir élististe. Cette approche serait très extensible et très intéressante en vue d'utiliser les fonctions les plus avancées de reiserfs4.
Le défaut : ben, si dans un navigateur, celui-ci a déterminé d'avance (et l'utilisateur sait donc tout de suite) s'il va s'agir d'une copie traditionnelle ou d'une importation/exportation, ce n'est pas le cas en ligne de commande.
Et là, boum, nous sommes en train de transformer la commande "cp" en une commande interactive. Ouch, c'est quelque peu embétant pour l'esprit unix et l'automatisation des tâches.
La seule solution que je vois : le plus simple est d'avoir un mode interactif et un mode non-interactif. Dans le mode non-interactif, il applique les règles d'exportation et d'importation, et ça pourrait être le mode non-interactif qui serait celui par défaut. On pourrait aussi avoir un mode où il ferait une copie comme maintenant, où on perd les informations supplémentaires (comme le propriétaire du fichier et les droits d'écriture/lecture/exécution). Ces deux modes combinés permettrait de retrouver le comportement traditionnel, et pourrait être posé comme modes par défaut si l'utilisateur le désire.
Ça fait un petit bout de temps que je pense à tout ça, car je vois reiserfs4 qui va débarquer, et on ne va rien en faire du tout pour rester compatible avec l'actuel, alors que : https://linuxfr.org/comments/317399.html(...)
[^] # Re: Linux ou Windows, faux débat
Posté par JSL . En réponse au journal Linux ou Windows, faux débat. Évalué à 2.
1) dans le meilleur des mondes, tous les systèmes de fichier supporteraient l'attribut type-mime, et personne ne parlerait d'extension de nom de fichier, donc la configuration par défaut se passerait de commentaire
2) mais il faut pouvoir cohabiter avec des partitions windows, ou utiliser son balladeur mp3. pour ce dernier cas, on touche le fond : on en a encore pour au moins 10 du système de fichier FAT.
Résultat ? Ben soit on attend ad eternam, soit on essaye d'évoluer en restant compatible avec l'ancien.
Alors voici ma vision du problème :
- on admet une bonne fois pour toute que l'arborescence / n'est pas d'un seul tenant, que derrière chaque point de montage se cache des systèmes de fichier différents, certains très basiques., sans perdre de vue qu'il y a quand même des points communs qui font que c'est justement pour ça qu'on peut les réunir dans une grande arborescence.
- quand on cherche à copier/déplacer en restant sur le même type de filesystem (même si c'est une autre partiation), il s'agit bien d'une copie/déplacement standard
- quand on cherche à copier/déplacer d'un ext3 version 2.6 (celui qui supporte les attributs supplémentaires) vers un système de fichier genre FAT (pour donner une idée du niveau), ce ne serait plus une copie qui serait proposé, mais une «exportation», avec un panneau qui s'ouvrirait en disant les modifs qu'il va faire, et après on choisirait entre [laisser tomber|copier avec les modifs proposées|copie brute, on perd des infos au passage mais tant pis].
- inversement de FAT vers ext3, ce ne serait pas une copie, mais une «importation» (noter le message subliminal dans l'utilisation des mots exporter et importer), suivant le même modèle. Dans le cas de l'extension, on la traduirait en type-mime, puis on l'enleverait du nom de fichier
L'avantage : il n'y a pas d'options à choisir pour l'utilisateur lambda, et il n'a qu'à dire «ok» pour l'importation et l'exporation s'il ne veut pas «se prendre la tête». Ça permettrait donc de commencer à exploiter les possibilités nouvelles des fs sans abandonner la compatibilité avec l'ancien, ni devenir élististe. Cette approche serait très extensible et très intéressante en vue d'utiliser les fonctions les plus avancées de reiserfs4.
Le défaut : ben, si dans un navigateur, celui-ci a déterminé d'avance (et l'utilisateur sait donc tout de suite) s'il va s'agir d'une copie traditionnelle ou d'une importation/exportation, ce n'est pas le cas en ligne de commande.
Et là, boum, nous sommes en train de transformer la commande "cp" en une commande interactive. Ouch, c'est quelque peu embétant pour l'esprit unix et l'automatisation des tâches.
La seule solution que je vois : le plus simple est d'avoir un mode interactif et un mode non-interactif. Dans le mode non-interactif, il applique les règles d'exportation et d'importation, et ça pourrait être le mode non-interactif qui serait celui par défaut. On pourrait aussi avoir un mode où il ferait une copie comme maintenant, où on perd les informations supplémentaires (comme le propriétaire du fichier et les droits d'écriture/lecture/exécution). Ces deux modes combinés permettrait de retrouver le comportement traditionnel, et pourrait être posé comme modes par défaut si l'utilisateur le désire.
Ça fait un petit bout de temps que je pense à tout ça, car je vois reiserfs4 qui va débarquer, et on ne va rien en faire du tout pour rester compatible avec l'actuel, alors que :
https://linuxfr.org/comments/317399.html(...)