[F] iPad (Informatique et high-tech) - Page 350

Idem, jamais de souci avec NTFS-3G, que j'utilise sur plusieurs machines successives depuis la première version publique. NTFS-3G est habituellement connu pour être très fiable, justement.

Perso, j'ai eu des problèmes avec NTFS-3G, même si le bug était plutôt dans les drivers Windows. Je m'explique : si la partition Windows était mise en veille prolongée, et que l'on rebootait sous Linux et que l'on modifiait des fichiers sous la partitions Windows. Alors au prochain reboot de Windows, toutes ces modifications n'étaient pas prises en compte : en fait, Windows en mise en veille prolongée ne recharge pas les données de configuration de NTFS depuis le système de fichier mais depuis sa RAM qui avait été stockée sur le disque dur.

ah c'est un sacré bug bon a savoir ca

Les logiciels de virtualisation ont plein de checks pour éviter ces problèmes. C'est clair que ça te pourrit tout de par exemple foutre en veille une partition Bootcamp via Parallels et booter dessus après (et justement le soft t'empêche par défaut de le faire, il ne reporte pas dans l'ACPI qu'il est capable de veille prolongée).

PpHd > pas sûr que ce soit un bug. Plus exactement, il est pas dit que ce soit un cas d'utilisation supporté.

Godzil (./10469) :
ExFAT par fiable?

J'ai pas dit ça. Il manque juste les permissions et sous OS X, ça m'a posé des problèmes. Mon disque externe est en exFAT ça me va très bien (sauf que c'est pas lu par la freebox )

Godzil (./10469) :
les machins a la NTFS 3G, ou meme le driver HFS(+) de Linux sont des nids a problèmes

(d'où mon choix d'une "vraie" solution).

Godzil (./10469) :
Perso je ne confierais pas mes données a un drivers "externe" a l'OS que j'ai choisis, mais c'est ton choix, si ca marche pour toi, tant mieux

Je n'y confie pas mon système mais seulement mes DATA, qui sont par ailleurs sauvées ailleurs.

Brunni (./10474) :
C'est clair que ça te pourrit tout de par exemple foutre en veille une partition Bootcamp via Parallels et booter dessus après

Oui j'ai eu fait (je trouvais classe de pouvoir virtualiser un physique qui reste bootable en physique.) Je referai pas!

Je m'en sers tous les jours, je boote ma partition Windows 8 majoritairement en tant que VM via Parallels mais de temps en temps, genre dans les weekend code/jeu où les performances légèrement supérieures me rendent heureux je boote physiquement dessus. Hop, 20 secondes pour booter quelle que soit la solution.

Perso avec une utilisation de presque 10 ans de ntfs-3g et des amis qui utilisent quotidiennement (mais sous linux pas OS-X) je n'ai jamais entendu parlé d'un soucis, donc dire que c'est instable ça me parraît très limite (mais j'ai envie de dire, comme d'habe lorsq'il s'agit d'avis de mac users, ils ont toutes les merdes du monde).

Brunni (./10474) :
et justement le soft t'empêche par défaut de le faire, il ne reporte pas dans l'ACPI qu'il est capable de veille prolongée

Oula, le workaround hardcore.

Mais au moins c'est safe pour les données, c'est ce qu'on demande à un FS ^^

Zerosquare -> je rejoins quand même PpHd, parce que dans le cas d'un disque externe, il se passe quoi ? Tu passes en veille prolongée, tu utilises le disques ailleurs, puis tu rebranches avant de sortir de veille ? Ca ressemble plus à un problème de concept, même si c'est un corner case. Probablement pour gagner quelques pouillèmes à la mise en veille.

Les disques amovibles (comme l'USB) ne sont pas concerné par ca, ton disque dur principal n'est pas amovible justement il n'est pas sensé disparaitre

Voilà. Les disques amovibles ne sont pas gérés de la même façon que les disques fixes par Windows (notamment la gestion des caches est différente). Ça ne me semble pas absurde qu'ils aient conçu la feature pour un usage classique (avec un seul OS) sans penser aux autres cas.

Absurde je dirais pas, mais très nombriliste, oui. Surtout que ça leur coûtait pas grand chose de faire comme s'il existait d'autres systèmes d'exploitation. M'enfin...

C'est pas si sûr pour le "pas grand-chose". Raymond Chen en parlait sur son blog, et même si ce n'est évidemment pas une source neutre vu qu'il travaille pour MS, il expliquait que le coût des features était lourd (à cause de toutes les configurations possibles, qui nécessitent d'être testées, d'être supportées après la release, etc.). Même si je ne suis pas entièrement convaincu par l'argument, il n'est pas absurde.

Et puis MS a compris qu'il y avait d'autres OS, ils font même du code open-source pour Linux, maintenant

Ca coute beaucoup en temps d'execution, parceque ca demanderais pour partir en veille d'etre sur que TOUT est propre et que rien ne reste a ecrire sur le disques. Je pense que c'est virtuellement impossible, et je doute que linux fasse beaucoup mieux tu sais..

(et pour le coup, je pense que le problème se produirait de la même façon avec un dual-boot avec deux versions de Windows, donc ça n'est pas une question de concurrence d'OS. J'imagine que changer la config matérielle et reprendre une sessions en veille prolongée pose problème également.)

Godzil (./10486) :
Ca coute beaucoup en temps d'execution, parceque ca demanderais pour partir en veille d'etre sur que TOUT est propre et que rien ne reste a ecrire sur le disques.

Bien sûr que pour partir en veille il faut que plus rien ne soit à écrire sur les disques ! Ça me parait une évidence.

C'est virtuellement impossible et le temps de mise en veille de Windows est déjà problématiquement long (enfin moins si tu as un PC sans ventilo ni LED power ni disque dur qui risque de s'endommager si tu le trimballes dans un sac alors qu'il tourne) donc les optimisations qu'ils ont fait depuis Vista allaient plutôt dans le sens de réduire le temps nécessaire pour partir en veille.

Je suis étonné, il y a combien en cache ? Quelques dizaines de mégas, maxi ? C'est quand même pas le temps que ça prend, à moins qu'ils aient été dans l'optique "on ture par tous les bouts".

Ce n'est pas qu'une question de taille de cache, mais il faut que les app acceptent d'aller en veille, les mettre en veille etc.. Il faut aussi etre sur que TOUTES les couches (app comprises) ai vidé leur cache etc...

Windows est un OS assez chargé question process, et la mise en veille a toujours été un process long et couteux, et dumper tous les caches sur le disque (donc vider ce qui est potentielleent en mémoire) est tres tres couteux en temps, car non trivial.

Si il n'y avais que le cache du disque ca serait un autre probleme..

redangel (./10468) :
-HFS avec Paragon: maintenant que j'ai compris l'erreur (sans savoir d'où elle vient), tout semble bien.

J'ai parlé trop vite
Enfin ça a été pendant 15 jours, et puis là j'ai un "gros" souci: "OS X n'est pas en mesure de réparer le disque "DATA". Sauvegardez le disque et reformatez-le dès que possible.", DATA étant ma partition partagée osx/win en HFS+
-Windows n'a aucun souci pour écrire dessus (avec paragon)
-OS X voit le volume comme "non inscriptible", donc lecture seule.

Je ne peux même pas vous montrer une copie d'écran, car mon dossier Desktop est sur DATA, et la copie d'écran native d'OS X me retourne "Impossible d'enregistrer votre capture d'écran".
J'ai essayé de réparer les permissions (en ligne de commande), ça essaye 3x sans succès. J'ai essayé depuis une clé usb d'install OS X, pas mieux.
J'ai essayé "SOS" dans l'Utilitaire de disque (qui revient à une réparation, je crois...):
"Le nombre d'attributs étendus est incorrect (normalement 6669 au lieu de 6670) [...] Le volume DATA n'a pu être réparé après 3 tentatives."

Origine possible du problème: j'ai pas trouvé mais les dernières manips étaient sous windows, j'ai installé Daemon tools (mais PAS sur DATA!), monté une ISO présente sur DATA... je vois pas la boulette.

Si quelqu'un a une idée, je suis preneur!

Sinon, bin je vais vider la partoche, déplacer mes comptes utilisateurs, formater comme indiqué, sans réinstaller tout... mais ça m'ennuie, je viens d'installer 35GO de jeux steam...

Probable que tu aies une desynchro entre la table de partition EFI et MBR. Windows se permet alors d'écrire sur sa propre partition à un endroit où commence déjà la partition HFS. Oui c'est tout à fait possible si tu as créé la partition HFS après avoir fait ton bootcamp, suivant les outils que tu as utilisés.

./10492 > Il existe d'autres utilitaires de réparation de disque (HFS+) que celui de OSX, avec de bien meilleurs résultats. (Entre autres DiskWarrior… je crois)
Maintenant, les drivers HFS pour Windows ne sont pas sans défauts, donc ton problème peut venir de là.
Ou bien, tu as mis en veille prolongée ton Windows et modifié la partition HFS+ depuis OSX avant de redémarrer Windows ? (cf. le problème évoqué quelques posts au dessus. ça m'est déjà arrivé et ça fait bien chier.)

Non je fais rigoureusement attention à jamais veille prolongée (par contre j'ai fait un peu de veille, mais ressorti sous le bon OS).
Je vais tenter DiskWarrior.
Brunni> Intéressant ce que tu dis sur l'EFI, mais je comprends pas d'où ça vient. Cela étant, ça se corrige?

Il y a une autre source possible d'erreur (mais ça m'étonne vraiment), j'ai utilisé un script qui portabilise un jeu (vieux... Outlaws) sur mon C: en utilisant les ISO présentes sur la partition DATA. Et ce script (batch) a plantouillé avant la fin.
Mais quand même, le rapport est vraiment lointain..

testdisk a déjà fait des miracles chez moi, si ça peut t'aider.

C'est juste une commande unix? Ok je vais y voir.
J'ai récupéré DW, en le lançant sous OS X, il me dit que le disque est réparable, mais en lançant la réparation il me dit qu'il faut le faire depuis une clé de restauration. A suivre.

Pour ce genre d'erreur, DiskWarrior m'a sauvé les disques à chaque fois en corrigeant tout sur les partitions HFS/HFS+. Testdisk en dernier recours sinon.

testdisk est un petit soft, écrit par un Français d'ailleurs.

Mais je doute qu'il soit utile dans ce cas, le probleme n'est pas une partition disparue, mais un probleme dans le systeme de fichier, testdisk ne peux rien pour ca.