c'est surement tres con comme question, mais ca fait une bonne demi-heure que je cherche...
 
J'ai un fichier que j'ouvre en mode r+
un peu avant la fin du fichier j'écrit mes données qui doivent se trouver a la fin du fichier.Si elles sont plus longues que celles qui existent deja,pas de probleme.
Par contre si mes nouvelles données sont plus courtes,il va rester a la fin du fichier les anciennes données.
 
Comment couper le fichier a la fin des nouvelles données ecrites?
PS:je prefererai eviter de réécrire tout le fichier (il fais plusieurs Mo)

Je délire peut-être :
Le close() sur le fichier, il ne met pas le caractère EOF à la fin, où on vient d'écrire ?
Les données seront derrière sur le disque, mais la relecture devrait ne donner que ce qui a été écrit (? ?). A tester...  
 
Sinon, dans le temps, il me semblait avoir vu écrire de force le caractère EOF (CTRL+Z ou ASCII 26, Cf http://support.microsoft.com/defau [...] ;Q253257&)
en binaire dans le fichier. Avec cette méthode, si la table d'allocation attend un fichier de 1Mo et qu'il y a EOF avant, ça fait désordre.

Non ça marche pas.
 
Je sais qu'avec l'API windows y a moyen de modifier la taille d'un fichier mais je sais pas si ça existe en C/C++ de base

et un truc du genre:  
ouvrir fichier en read
ouvrir un fichier tampon en w
recopie du fichier initial
 insertion de tes données
fermeture des fichiers
rename

pour preciser la situation,ce que je veux faire c'est mettre a jour le tag lyric3(de taille variable qui se trouve juste avant le tagId3v1 a la fin du fiochier) d'un fichier mp3 et ce pendant la lecture de ce fichier par winamp.
 
A mon avis c'est possible de le faire sans réécrire des données(qui je le rapelle,sont en cours de lecture par winamp).J'arrivais a le faire en delphi (il suffisait de mettre la propriété fileSize a la bonne longueur).
 
c'est pour ca que j'aimerai eviter une méthode comme celle de prettysmile car ca interomprait la lecture de winamp

Si t sous windows cherche du côté de SetFilePointer et SetEndOfFile.

ca marche avec SetEndOfFile
 

 
Merci

de rien

Il y a aussi la fonction C (io.h) chsize (allonge fichier avec des \0 ou raccourcit).
Sous Win32 bits, à voir (ça semble utilisable d'après le fichier HLP).

 
Je la connaissais pas celle là, je prend note
 
EDIT: par contre niveau portabilité, ça exite sur les système UNIX? (c juste pour ma culture perso )

Pour chsize, la portabilité est
DOS +
UNIX rien donc : non
Win16 +
Win32 +
ANSI C rien donc : non, itou
ANSI C++ rien
OS/2 +
 
Sous UNIX/Nunux, faudra trouver autre chose de même que pour remplacer SetEndOfFile(); .....

carbon_14 a écrit a écrit : Pour chsize, la portabilité est DOS + UNIX rien donc : non Win16 + Win32 + ANSI C rien donc : non, itou ANSI C++ rien OS/2 +   Sous UNIX/Nunux, faudra trouver autre chose de même que pour remplacer SetEndOfFile(); .....

 
C bien ce qu'il me semblait

Sous Win95/NT aussi. Donc leur descendant aussi ?
Si on la trouve pas, penser à mettre un _ devant, comme souvent les choses non-standard.
 
Je ne connaît pas de manière standard de fixer la taille d'un fichier.
Ça a l'air con ? Ça l'est.

carbon_14 a écrit a écrit : Pour chsize, la portabilité est DOS + UNIX rien donc : non Win16 + Win32 + ANSI C rien donc : non, itou ANSI C++ rien OS/2 +   Sous UNIX/Nunux, faudra trouver autre chose de même que pour remplacer SetEndOfFile(); .....

 
sous nunux le EOF n'est il pas un define de \0 ???
donc foutre un \0 en plein milieu de ton fichier reviendrais a le couper en 2 mais sa taille serrais pas retrecit mais bon :? ya ptet un truc ke joublie

koulip31 a écrit a écrit :     sous nunux le EOF n'est il pas un define de \0 ??? donc foutre un \0 en plein milieu de ton fichier reviendrais a le couper en 2 mais sa taille serrais pas retrecit mais bon :? ya ptet un truc ke joublie

 
Le EOF ça marche que pour certains editeurs de texte sui s'arrétent quand il trouvent se caractère c tout

sous unix like il y a truncate()

Le caractère EOF est obsolete.

Arrêtez votre délire avec EOF les gars, c'est un caractère qui n'existe pas.
Pour les fonctions qui retournent les caractères sous forme d'entiers, lesdits caractères vont de 0 à 255, et EOF vaut -1.

 
Et -1 ce serait pas hazard: 0xFF ?
 
1) EOF existe.
2) Sa valeur dépend des système.

Mais bien sûr, comme ça quand tu lis un fichier binaire, il s'arrête en plein milieu parce qu'il trouve 0xFF.
 
Reprenons :
  255, c'est 0x000000FF
  EOF, c'est 0xFFFFFFFF
 
Une fonction qui retourne un char ne peut pas retourner EOF, c'est uniquement le cas si elle retourne un int.

 
T'as pas tout compris au film toi. EOF est un caractère conventionel pour désigner la fin d'un fichier TEXTE . Ca n'a rien à foutre dans un fichier binaire. C aussi pour ça que les éditeurs de textes qui cherchent se caractère afin de trouver la fin du texte s'arrétent en plein milieu d'un fichier binaire.

La fonction retourne -1 pour dire "y a qq chose qui n'est pas normal", c'est pas pour ça que le caractère est -1. C'est un code d'erreur (fichier terminé).

Il n'y a aucune différence entre texte et binaire. L'éditeur qui cherche la fin du texte dans un fichier binaire va trouver la fin du fichier binaire.
 
Tu en veux, un caractère 0xFF ? Tiens, c'est ÿ en iso-8859-1(5).

 
Ben si y a une différence pour le programme sui l'ouvre. Dans un texte typiquement tu trouve pas '\0' (0 ou encore 0x00). Y a certaine convesions (saut de ligne, tabulations, EOF..) Et si t'ouvre un fichier dit "binaire", c'est à dire ne respectant pas les convension du ficheir texte, ben à priori c du nimporte quoi pour l'éditeur de texte.

La seule différence, c'est qu'il y a des caractères interdits, parce qu'ils ont une signification spéciale en ASCII : effacement, tabulation, changement de couleur... Mais le caractère 0xFF est parfaitement valide en ISO-8859-*, il ne signifie pas EOF. Il n'y a pas de caractère EOF.

 
 
j'ai pas dit que EOF avait une valeur variable plus haut? Ca dépend des os et des sytème, comme le reste d'ailleur (en particulier les retour de ligne). Putain boucher celui là!  
EOF existe (ou plutôt existait) et a été largement utilisé. Maintenent il l'est plus trop à ma connaissance.

Décidément, tu ne comprends rien à rien. Tu sais, tu peux reconnaître que tu ne sais pas, ce n'est pas une tare.

 
Bon he tu sais quoi maych nulle, repartons chacun de notre côté avec nos certitudes et sans rancunes.
On va pas se faire chier pendant 107 ans pour 8 bits à la con.

Jar jar > T'es débile ?
 
EOF est un des premiers caractères qu'on trouve dans la table ASCII...

http://users.cybercity.dk/~bse26236/batutil/ascii.htm
 
L'autre non de EOF est ETX pour "End Of Text"
 
Idem pour BOF qui s'appelle aussi STX.
 
Et EOF n'est présent que dans un fichier TEXTE.
 
Les fichiers binaires n'ont d'information sur leur taille que dans le système de fichiers.

 
  Merci vieu.
 
C moi qui étais pas clair ou quoi?

D'ailleurs, une petite correction...
 
ETX est OEF pour Unix, mais pour systèmes Microsoft, c'est SUB le code ASCII utilisé pour EOF.
 

Et pour fixer la taille d'un fichier, c'est décrit là :
 
http://users.cybercity.dk/~bse2623 [...] ORT.HTM#A4
 
Par contre, c'est un bact MS-DOS.
 
Faudra donc transcrire pour en faire du C

letoII a écrit a écrit :       Merci vieu.   C moi qui étais pas clair ou quoi?

Nan c'est Jar Jar qui passe son temps à contredire tout le monde.
Alors forcément à un moment il ne peut que dire une connerie.
 
PS: Par contre, pour ton fichier, chuis pas sûr que ça puisse marcher, vu que les MP3 sont en binaire
 
Essaie toujours

Mais voilà que mon petit boulay perso vient m'expliquer comment marche un système de fichiers maintenant

Je crois qu'en effet, tu n'as pas bien compris comment ça marche.
 
Mon grand dieu aurait-il oublié ses cours ?

Benh ouai, ca se tappe dessus, je veux lire la suite du topic