Bonjour,
Je me demandais s'il existe une méthode rapide pour écrire un fichier (genre 4go) avec que des zéros dedans?
Un truc à base de seekp a l'air de me créer un fichier de la taille voulue, mais je ne sais pas s'il est garanti qu'il soit rempli de zéros ou plutot de valeurs non initialisées?
 

 

 
C'est suffisamment rapide, ca écrit à 200MO / sec sur un disque dur SSD.

 
ouais mais en c++ et windows compliant je peux faire quoi?
 

 
 
C'était un peu d'humour désolé
 
J'ai regardé l'aide sur la fonction seekp , rien ne dit que le fichier sera rempli de 0. Un bon moyen de savoir est que si tu fais ton seek de 4 GO et que la fonction retourne instantanément ( au close du stream bien entendu ), c'est qu'il n'y a aucune action de faite sur les données contenues dans le fichier. Dans ce cas, le fichier prend les valeurs qui étaient précédemment sur disque, c'est à dire indéterminé.
 
Le mieux est de boucler sur ton fichier et d'écrire des segments remplis de 0 ( tu peux faire ça avec un buffer de 16-32-64 MO sans problème ,il y a de grandes qu'il soit mis dans le cache du disque dur ). Dans tous les cas , pour 4 GO , ca mettra de 20 sec ( à 200MO par sec sur un SSD comme je te l'ai indiqué ) à 80 sec ( 50MO/sec sur un sata classique ).

D'ac
J'avais essayé ce matin en écrivant des morceaux de 1k de zéros.
Je pouvais pas écouter si le disque moulinait ou quoi, mais il a bloqué vers 2Go (looooooongue pause) et repris pour finir jusqu'aux 4Go. Ca m'a paru bizarre. ET j'ai eu le temps de faire chauffer le café en attendant...

Il existe des programmes qui peuvent créer d'énormes fichiers (je m'étais amusé à taper dans le 500Go, en gros) instantanément. Donc je suppose qu'il doit exister des méthodes pour le faire

Je ne sais pas ce que se passe sous Windows, mais sous Unix un seek va permettre de créer un fichier remplis de bytes à 0 et ne prenant pas de place sur le disque (donc la création d'un tel fichier est à peu près aussi rapide que celle d'un fichier vide).

Je pense que c'est le même délire sous Windows, à tester

 
 
Je ferai un test, mais j'ai de sérieux doutes. Je ne vois pas comment le fichier peut contenir des 0 sans effectuer une opération sur le disque. Ou alors, tu sous entends que le fichier ne prend pas de place tant qu'on n'a pas fermé le descripteur, et à la fermeture , il flush les écritures , et ce sera long à ce moment là. Non ?

Des fichiers "sparse" ?
L'idée, c'est de définir la taille du fichier mais sans l'écrire totalement ni même allouer la place :
http://blogs.codes-sources.com/cyr [...] 16351.aspx

 
Un open suivit d'un seek et d'un write.
 
Le seek va juster incrémenter la valeur de l'offset.
 
Lors du write on ne va allouer que les éventuels blocs d'indirections nécessaires plus les blocs du write => peu d'écriture et en plus y'a le buffer cache qui va retarder l'écriture des blocs.

 
 
Effectivement, je viens d'effectuer ce petit programme de test (c'est du C par contre ) :  
 

 
Effectivement le programme retourne quasiment instantanément, et le fichier contient bien des 0 ensuite (sauf à la fin ), vérification en tapant od -h titi.dat.
 
J'ai du mal à comprendre le mécanisme, si je crée le fichier en le remplissant de 0 à la main, ça met plus d'une minute.

On n'écrit rien sur le disque: la table indiquant les secteurs utilisés pour le fichier contient pour ces zones une indication qu'aucun secteur n'est alloué.

 
 
Ok, c'est donc une spécificité du système d'exploitation. Je ne savais pas que cela fonctionnait comme ça. Mais ça nécessite que l'OS ( le driver du système de fichier) tienne une table de secteurs à 0 en plus de la table d'adressage des fichiers. Pas sur que ce soit aussi efficace qu'un fichier réellement rempli de 0 , lorsque ce fichier vient à être morcelé de petites parties , comme par exemple un fichier torrent qu'on est en train de télécharger.
 
Merci de l'info en tout cas  

 
1° T'entends quoi par table d'adressage des fichiers et table de secteurs?
 
2° T'entends quoi par lorsque ce fichier vient à être morcelé de petites partie?

Si tu vois ton fichier comme une liste chaînée de secteurs, oui.   Si tu le vois comme un tableau de secteurs, il suffit de prévoir que qu'une entrée dans le tableau puisse être invalide.  Les unix sont dans la seconde tradition (qui permet un accès direct plus rapide).

 
 
Pour accéder à un fichier, il faut bien une table qui indique à quel secteur se positionner. C'est ce qu'on appelle la FAT ou la table d'inode par exemple selon le système de fichier utilisé. Je sais qu'un fichier peut ne pas être contigu, et dans ce cas, selon la méthode d'adressage, l'OS ( le driver ) tient une table de tout ce qui peut composer le fichier. Maintenant, je ne savais pas qu'en plus ( mais ça parait logique en y réfléchissant) qu'il est capable de prendre en compte des secteurs remplis de 0 sans qu'ils le soient réellement (c'est bien ce qui a été dit non ? ). Dans ce cas, il y a bien quelque chose qui indique que tel bloc de secteur est un bloc composé de 0, ça peut être un flag par exemple.  
 
Ce qui signifie, si je ne me trompe pas, pour un fichier créé de cette façon, qu'il ne sera pas représenté dans sa table d'adressage , de la même manière qu'un fichier remplis réellement de 0, ce qui implique donc une différence de performance. Après, elle est peut-être insignifiante.
 
 
Pour le point 2, j'ai pris un exemple d'application qui écrit dans le fichier de façon aléatoire (selon ce qu'il a reçu ), la table d'adressage du fichier va constamment être mise à jour, j'ai l'impression que ce n'est pas une bonne chose.
 
 
edit :  
 

 
 
Ok, je comprends mieux  

Merci pour toutes ces précisions    En espérant que ça serve également à l'auteur du topic !

ouep, je lis, je lis.
Donc si j'ai bien compris, oui j'ai bien mon fichier rempli de "zéros" mais le temps gagné en faisant ça sera perdu quand j'écrirai mes vraies données dans le fichier

La principale utilité est le gain d'espace disque (les 0 ne sont pas écrits et si c'est pour un fichier indexé, il peut y avoir des zones où on n'écrira jamais), mais si tu ne gagnes rien par rapport à écrire directement la valeur finale, tu gagnes quand même par rapport à écrire des 0 puis la valeur finale.

 
C'est cool c'est ce que veux. Je sais que j'écrirai dans tout le fichier, mais je ne sais pas dans quel ordre. Ca donc ça me permet de me réserver l'espace pour la suite.    
 
Et puis bon, on peut maintenant revenir aux disquettes puisqu'on sait qu'on peut stocker une quantité illimitée d'informations dans un espace nul    

Je ne sais pas quel FS a implémenté ça le premier, mais la première fois que je l'ai vu, c'est il y a bien longtemps, sous SUN OS et son FS de l'époque. L'équivalent sous NTFS est arrivé plus tard.
A+,

 
C'est au moins possible depuis Unix V7.