Je CRRAAAAAAAAAAAAAAAAAAAQUE avec ce XP de m****** . Quel est le c** qui a pensé les MFC? Même motif marche mieux !!!
C’est pas un troll, c’est un appel au meurtre : la tête de Bill !
Encore un mois sur cette bête et je file ma dem’, c’est insupportable.
(Désolé c’était la gueulante du moment. Si quelq’un à un projet intéressant en linux qu’il fasse signe avant qu’on me retrouve en hopital psychiatrique :
Mais pourquoi avez vous brisé TOUTES les fenêtres de TOUT le quartier, une par une ?
Windows de mer**
Pourquoi avez vous laissé chargé votre gnou dans la vitrine de l’opticien ??
Visual Studio de mes …
Je m’appelle Madame Françoise Calmette, pourquoi vous obstinez vous à m’appeler Quantin Tessard?
quand on deplace ourenomme un fichier on change juste des infos dans l’inode (ou quelque chose comme ça.
le fichier ne bougeant pas physiquement, les applictions ouvertes dessus ne le perde pas, ça ne pose aucun problème.
pour la suppression c’est pareil, et si un logiciel enregistre dans ce fichier, il est recréé automatiquement.
Donc je vois pas pourquoi on aurais besoins de cette « sécurité »
AdminOfPlaygroup : le problème c’est qu’il m’empêche de le faire, alors que linux ne m’empêche pas, et que ça n’entraine pas de corruption pour autant (notion de filehandle). Tu déplaces un fichier pendant son écriture, sans que ça pose de problème.
La « sécurité » dont tu parles est liée au fait que l’emplacement d’un fichier est lié directement à la donnée, sans passer par un intermédiaire (une référence appelée filehandle). Lorque tu déplaces/modifie un fichier dans l’arborescence, tu n’en changes que la référence, les données ne bougent pas.
Ca explique également l’incroyable lenteur de Windows à supprimer des fichiers puisqu’il doit attendre que tous les processus aient fini de les utilsier.
Je pensais que Windows avait réglé ce (gros) problème, car c’est un des fondements du multiusers (supprimer un donnée sans affecter le voisin qui est entrains d’utiliser cette donnée)
Edité le 03/04/2009 à 11:14
Et bien Windows NT fonctionne autrement. :neutre:
Et ce n’est pas un problème… c’est différent !
Et non, on ne peux pas modifier quelques chose qui existe depuis 20 ans !
Pour moi, le fondement du multi-utilisateurs est justement de ne pas laisser manipuler un fichier verrouillé par un autre utilisateur. :neutre:
AoP : non, bloquer l’utilisation par un à un autre utilisateur n’est pas transparent. Il s’agit que plusieurs personnes utilisent la machine sans avoir conscience qu’il y a plisuers personnes.
NT fonctionne autrement, mais NT me fait perdre du temps.
C’est normal, tu as été habitué à une autre méthode.
Mais tu es là pour rétablir l’ordre. :mdr
Pour moi, justement, l’autre personne dois avoir conscience que le fichier est utilisé !
Sinon, il se passe quoi, c’est le dernier qui enregistre qui a raison ? Ridicule !!!
Qu’est ce que tu réponds à l’utilisateur qui te demandes où sont passées les deux heures de travail qu’elle a passé à modifier un document ?
Si A supprime un fichier ouvert par B mais que B enregistre après que A ait supprimé, alors la version de B reste enregistrée. Dans tous les cas ce ne sont que des références aux fichiers, le fichier est réellement détruit que lorsqu’il n’y a aucune référence dessus.
Sinon tu as des notions de fichiers utilisés ailleurs et de locks, comme partout, pour éviter ces risques quand c’est nécessaires.
Edité le 03/04/2009 à 11:52
Et A m’appelle : pourquoi le fichier que je viens de supprimer existe encore ?
Voir mieux, A remarque que son fichier existe encore et le supprime de nouveau après que B est enregistré.
Dans mon exemple, A ouvre un fichier et commence à le modifier, B ouvre le même fichier, le modifie et le ferme, puis A enregistre et ferme.
Que sont devenues les modifications de B ?
Perdues, en toute transparence. :paf:
Edité le 03/04/2009 à 12:05
A un moment il va bien falloir que A et B se rendent compte qu’ils utilisent la même données. D’'où l’intérêt de séparer les comptes.
Ce mécanisme est surtout pratique pour gagner du temps, pour éviter de bloquer un programme qui lit un fichier quand celui ci est déplacé. C’est à dire pouvoir modifier la référence d’un fichier sans en changer le contenu.
Lorsqu’on touche aux données elles mêmes, les conflits sont inévitable, de n’importe quelle manière que tu t’y prennes. En outre comme je te le disais les logiciels signalent que la donnée a été modifiée de manière externe entre temps.
Je trouve absurde qu'on ne puisse pas modifier le nom d'un fichier pendant qu'il est utilisé. Ca ne porte pas à confusion.
Je crois qu’on ne se comprends pas. Tu parles de données je parle de références aux données. C’est la même chose sous windows, mais pas sous linux. Il n’y a pas de risque de perte non plus sous linux. Le seul risque est de supprimer un fichier et qu’il soit réécrit par un programme qui l’utilisait et qui fait une opération d’écriture. B ouvre un fichier, A le supprime, B l’écrit. Le fichier final reste présent. En fait on a les avantages de la sécurité windows, moins les messages d’erreurs lorsque tu déplaces un répertoire complet dont des fichiers sont en cours d’utilisation, ce qui est un gain de temps considérable.
Penses la notion de filehandle comme celle de pointeur. Tu peux avoir plusieurs pointeurs sur la même donnée sans qu'elle ne change.
Edité le 03/04/2009 à 15:46
Non, mais là je te confirme pour la perte de temps!!!
Je suis entrains de faire une copie d’un répertoire et MoÔÔÔonsieur Windows ne veut pas parce que j’ai des programmes qui utilisent ces fichiers : mais qu’est ce qu’il en a)à f****. Et l’interface avec Subversion, je rigole… ppffffff …
Du coup me voilà à fermer tout mon taf pour un malheureux backup.
Edité le 03/04/2009 à 17:07
« Oui, c’est pour ça que Windows NT verrouille les fichiers ouverts en écriture. » Ce qui est une superbe faute de design comme l’explique v_atekor.
Ca marche mais c’est très sous optimal dans pas mal de cas.
Si tu avais la notion de référence aux données, il n’y aurait plus de raison de locker les fichiers ouverts en écriture.
Moi je trouve ça optimal au contraire !
C’est vrai qu’on a tellement souvent l’occasion de renommer, effacer ou déplacer un fichier sur lequel quelqu’un travaille !
J’aimerais savoir le contre-coût de la « meilleure » technique qu’utilise GNU/Linux !
Je ne pense pas que Microsoft ai choisi d’ignorer cette voie sans raison.
J’ai très souvent modifié des méta données de données sur lequelles je travaille, et encore plus souvent copier des données pendant que je les utilise
Ils l’ont zappé pour cause de compatibilité ascendante, notamment avec les programmes de feu DOS qui n’étaient pas du tout équipés pour ce genre de trucs. Mais inutile d’essayer de les sauver sur ce coup sans passer pour l’avocat du diable. OS/2 devait régler ce problème, mais tu sais ce qu’il en est advenu … il y a 15 ans…
Edité le 03/04/2009 à 18:17
