bonjour,
 
je voudrais savoir s'il existe un moyen en C ou C++ de tronquer un fichier par le début. Supposons que l'on ait un fichier toto.txt, ouvert ou non. Je voudrais supprimer les 2 premières lignes de ce fichier, ou les 50 premiers octets.
Bine sûr, le but du jeu est de ne pas devoir recopier ce que l'on veut garder puis de tout recopier en se placant au début.
 
Il me semble que c'est possible avec certains unix avec la fonction 'fcntl' et le mode 'F_FREESP', mais je ne trouve pas d'équivalent sous linux ni sous windows. Bref, pas très portable.
 
Si vous avez des idées....

?
De mon point de vue, comme les octets se trouvent à la suite les uns des autres, si on veut en supprimer un bloc, à moins de pouvoir METTRE A JOUR LA TABLE D'ALLOCATION ET que ça tombe sur une unité de stockage RONDE, le moyen direct est de recopier en écrasant les octets à supprimer.    
 
Si la table d'allocation permettait d'atteindre tout octet (granularité 1), il suffirait de déplacer le pointeur sur le fichier. Si on a des blocs de 4k, 16k, 32k, etc.. comme sous DOS/Win, on ne peut accéder qu'à une adresse "multiple".
 
La fonction 'fcntl' fait peut-être ce travail à la place de l'utilisateur. A moins que le système de fichiers permette une très grande souplesse dans l'adressage.  
 
Si qq a une idée plus constructive ?

il faut bidouiller directement la table d'allocation , ce qui est un peu hard.
ce serait pour de gros fichier ? sinon , avec read et write ca ne devrai pas etrre trop long .

> ce serait pour de gros fichier ? sinon , avec read et write ca ne devrai pas etrre trop long .
 
Aujourd'hui je travaille sur des petits fichiers et donc ce n'est pas trop long. Le probleme se pose justement si je veux traiter des gros fichiers...
 
>La fonction 'fcntl' fait peut-être ce travail à la place de l'utilisateur. A moins que le système de fichiers permette une très grande souplesse dans l'adressage.
 
et bien justement, extrait du man:
#man fcntl
---------------------------------------------
(...)
Note that all filesystems  might  not  support
all possible variations of F_FREESP arguments.
In particular,  many  filesystems  only  allow
space to be freed at the end of a file.
(...)
 
 
Donc outre le fait que toutes les plateformes n'implémentent pas cette fonction, il y a en plus des limitations selon le system de fichier, en effet. Autant aujourd'hui les systemes de fichiers sont encore à peu près toujours les mêmes, autantcela devient moins vrai, surtout sous linux.

Je ne vois pas ce que tu veux par contre pas la peine de copier une fois puis de recopier ce que l'on veux tu peux directement deplacer des blocs dans le fichier :
 
tu lis de n+i a n+i+k et tu copie a entre i et i+k
i +=k;
et tu recomances jusqu'a la fin et tu as enleve les n premieres lignes...

[edtdd]--Message édité par BENB--[/edtdd]

Il voudrait un moyen pour dire au système : mon fichier fait 218 caractères de moins au début, et que cela se fasse tout seul sans intervention programmatrice  .
 
Si ce sont des fichiers d'accès répété, il y aurait moyen de gérer une liste d'adresses qui donne le début réel de chaque fichier (donc sans les altérer). Suffit de faire un seek à l'adresse pour se trouver au "début" des données...

 
tout à fait d'accord avec toi. Sauf que quand tu fais cela avec un fichier qui fait 15Mo, et que tu dois le faire souvent, c'est long. Imagine que tu doivent écrire des traces toutes les secondes dans un fichier qui ne doit pas faire plus de 15Mo. Même si tu n'écris pas grand chose à chaque fois, mais que ton appli doit tourner pendant des jours et des jours sans s'arreter, alors  la limite est vite atteinte.
Aujourd'hui, j'ai un vecteur de string et à chaque fois je flush tout dans un fichier. Je n'ai donc pas besoin de copier/couper déplacer à l'interieur du fichier.
Mais quand le fichier devient important, cela devient pénalisant.
 
J'espere m'être fait comprendre...

Si les données écrites ont TOUJOURS la même longueur et que le "décalage" est régulier (x écrit pour x périmé), faudrait fabriquer un genre de "FIFO". Le fichier fait 15Mo. On écrit ce qu'on a à écrire (< 15Mo). On gère l'adresse de début du fichier pour ce qu'il faut supprimer, et on ajoute le reste à la suite du fichier. Quand la fin physique est atteinte (15Mo), on écrit au début sur ce qui ne sert plus. La zone "effacée" se déplace dans les 15Mo.
Quand fini, on recopie tout dans un fichier neuf.  

Dans mon cas, je n'ai jamis fini de remplir le fichier.
Je veux continuer à inscrire des choses dedans tant que le programme tourne.
Et je veux pouvoir consulter ces traces régulièrement sans devoir arrêter l'appli.
Je ne peux donc pas savoir quelle sera la taille de ce fichier.
De plus, A ne pas flusher le texte de façon régulière dans le fichier, on risque
de tout perdre encas de crash de l'appli, ce qui peut être gênant.
 
Un fichier "circulaire" est en effet une solution. Les seuls "vrais" inconvénients sont les suivants:
1. C'est désagréable à lire est cela oblige à mettre un timestamp sur toutes les traces pour savoir ou on en était quand on s'est arrété.
2. Quand tu as un fichier de 15Mo et que tu ne sais pas où commencer la lecture, c'est lourd

heu juste comme ca, puisqu'on parle de fichier, kk1 connaitrait'il une bibliotèque qui permette de gérer des fichiers de configurations, genre les fichier .ini de win (si possible qui existe aussi sous unix ...) mercie

J'ai parcouru rapidement ce qui a été écrit (ça doit être pour ça que je comprend pas bien ce que tu veux faire ) mais si le seul truc qui t'embête dans un fichier ciculaire c de pas savoir ou sa commence je te conseil de mettre un header qui contient cette info, éventuellement la taille des entrées (si elle est constante dans le fichier), ce qui évite le time stamp, et tu te fait un petit prog qui te ressort chaque entrée dans l'ordre