C'est encore plus fréquent de mettre un 0x26 au lieu de 0x00 dans un champs d'entête SMB2 ...
Ben tu vas me montrer une implementation SMB2 qui le faisait il y a 3 mois alors ?
Non mais n'importe quoi ... OpenAFS est un projet qui se développe depuis presque dix ans avec une jolie quantité d'utilisateurs[1]. Ça fait environ 5 ans que la version Windows existe. Donc depuis 5 ans des gens perdent des données ? Et personne ne c'est rendu compte ?
Ou alors "extrêmement fréquent" c'est un terme qui veut "presque jamais".
Jolie quantite d'utilisateurs ? Moi quand je vois leur liste je vois que c'est minuscule, c'est genre 10'000 utilisateurs. MS a lui tout seul en interne a 10x ca.
Quand au fait que personne ne s'en rendait compte, c'est justement ce que je te dis, ca fait peur, car OUI ecrire au milieu d'un fichier est une operation extremement courante, tu prends Office par exemple, il fait ca constamment, les softs qui jouent avec la video et autres mp3 aussi(c'est des frames ecrites les unes apres les autres le plus souvent, suffit de les rajouter/couper), etc...
Il est assez clair que ce FS est :
a) pas teste pour servir de FS generaliste
b) utilise en pratique dans des scenarios tres limites(tu vois les noms des utilisateurs, c'est tres oriente recherche)
PS: Généralement les programmes lisent le fichier en entier en mémoire et ré-écrivent le fichier complet (oui sauf les bases de données, mais ça c'est explicitement statuer qu'AFS ne convient pas pour les bases de données, et sauf peut-être les applications multimédia, mais la taille des fichiers ne convient pas à un système de fichier réseau).
Non certainement pas, je t'ai donne une liste plus haut, il y en a plein d'autres, et c'est encore plus justifiable en reseau, parce que reecrire tout le fichier est plus lent qu'en reecrire une partie. Sinon, les fichiers multimedia c'est certainement pas un probleme pour un systeme de fichiers reseau, on n'est plus a l'epoque des reseaux 10mb/s hein, on a ca en interne depuis des annees ici et ca marche tres bien.
[^] # Re: Bon, plusieurs problèmes
Posté par pasBill pasGates . En réponse au journal Serveurs de fichiers. Évalué à 1.
Ben tu vas me montrer une implementation SMB2 qui le faisait il y a 3 mois alors ?
Non mais n'importe quoi ... OpenAFS est un projet qui se développe depuis presque dix ans avec une jolie quantité d'utilisateurs[1]. Ça fait environ 5 ans que la version Windows existe. Donc depuis 5 ans des gens perdent des données ? Et personne ne c'est rendu compte ?
Ou alors "extrêmement fréquent" c'est un terme qui veut "presque jamais".
Jolie quantite d'utilisateurs ? Moi quand je vois leur liste je vois que c'est minuscule, c'est genre 10'000 utilisateurs. MS a lui tout seul en interne a 10x ca.
Quand au fait que personne ne s'en rendait compte, c'est justement ce que je te dis, ca fait peur, car OUI ecrire au milieu d'un fichier est une operation extremement courante, tu prends Office par exemple, il fait ca constamment, les softs qui jouent avec la video et autres mp3 aussi(c'est des frames ecrites les unes apres les autres le plus souvent, suffit de les rajouter/couper), etc...
Il est assez clair que ce FS est :
a) pas teste pour servir de FS generaliste
b) utilise en pratique dans des scenarios tres limites(tu vois les noms des utilisateurs, c'est tres oriente recherche)
PS: Généralement les programmes lisent le fichier en entier en mémoire et ré-écrivent le fichier complet (oui sauf les bases de données, mais ça c'est explicitement statuer qu'AFS ne convient pas pour les bases de données, et sauf peut-être les applications multimédia, mais la taille des fichiers ne convient pas à un système de fichier réseau).
Non certainement pas, je t'ai donne une liste plus haut, il y en a plein d'autres, et c'est encore plus justifiable en reseau, parce que reecrire tout le fichier est plus lent qu'en reecrire une partie. Sinon, les fichiers multimedia c'est certainement pas un probleme pour un systeme de fichiers reseau, on n'est plus a l'epoque des reseaux 10mb/s hein, on a ca en interne depuis des annees ici et ca marche tres bien.