[DOS/C] File inkorten. Wat doe ik fout?

[hneel]

Zoals misschien bekend is het mogelijk een file in te korten dmv een seek en dan 0 bytes schrijven.
Ik heb onderstaande progje geschreven, maar om een of andere reden werkt het niet. Hij eindigt wel met "Done".

C:

#include <stdio.h>

void main(int argc, char *argv[])
{
  FILE *fp;
  unsigned char buffer[10];

  printf( "Opening file %s\n", argv[1] );
  fp = fopen(argv[1], "r+b");
  if( fp == NULL )
  {
    printf( "Open failed\n" );
    return;
  }

  printf( "Seeking end\n" );
  if( fseek( fp, 0x0100, SEEK_SET   ) != 0 )
  {
    printf( "Seek failed\n" );
    fclose (fp);
    return;
  }


  printf( "Writing zero bytes\n" );
  fwrite( buffer, 1, 0, fp );

  fclose (fp);
  printf( "Done\n" );
}

Wat doe ik fout?

[Verwijderd]

hneel schreef op dinsdag 17 juli 2007 @ 14:41:
Zoals misschien bekend is het mogelijk een file in te korten dmv een seek en dan 0 bytes schrijven.
Ik heb onderstaande progje geschreven, maar om een of andere reden werkt het niet. Hij eindigt wel met "Done".

Wat doe ik fout?

Alles?

Je opent het bestand in r+b modus. Dit houdt in alleen-lezen en binaire modus. En verolgens wil je toch iets gaan wegschrijven?

Kijk eens naar de handleiding van fopen op bijvoorbeeld:
http://www.thinkage.ca/english/gcos/expl/c/lib/fopen.html

Al gekeken naar de mogelijke parameters voor fopen?

code:

w+
    open for both reading and writing. The stream will be created if it does not exist, and will be truncated if it does exist.

Overigens wordt je buffer nergens geinitialiseerd, en wordt er garbage als teken naar je bestand weggeschreven.

[.oisyn]

sinaasappelsap: Misschien moet je zelf eens naar die openmodes kijken, aangezien daar staat dat r+ voor reading én writing is, zonder dat er getruncate wordt (wat je ook niet wilt, aangezien je dan een lege file overhoudt als je niets schrijft)

hneel schreef op dinsdag 17 juli 2007 @ 14:41:
Ik heb onderstaande progje geschreven, maar om een of andere reden werkt het niet.

Definieer "het werkt niet". Blijft je file gelijk? Wordt ie 0 bytes? Wordt je hdd geformatteerd? Komen er ineens apen op je toetsenbord dansen?

En waarom controleer je overal error-codes, behalve bij die laatste fwrite? En als je bijvoorbeeld toch data schrijft (en dus niet 0 bytes), komt die data dan op die plek in de file te staan?

Overigens zie ik nergens het door jouw gewenste gedrag in de ISO C (99) spec gedocumenteerd staan.

[ Voor 59% gewijzigd door .oisyn op 17-07-2007 15:28 ]

[hneel]

Volgens mij moet het toch "r+" zijn.

Uit de link die je gaf:

r+
open for both reading and writing. The stream will be positioned at the beginning of the file.
w+
open for both reading and writing. The stream will be created if it does not exist, and will be truncated if it does exist.

Die buffer is maar dummy. Er worden immers 0 bytes geschreven. Misschien moet het ook gewoon met NULL kunnen, maar voor de zekerheid heb ik maar een "echte" buffer aangemaakt.

[.oisyn]

[It is implementation defined] whether a write on a text stream causes the associated file to be truncated beyond that point (7.19.3).

Dus als je implementation dat support, zul je 'm sowieso als text moeten openen.

[hneel]

Definieer "het werkt niet". Blijft je file gelijk? Wordt ie 0 bytes? Wordt je hdd geformatteerd? Komen er ineens apen op je toetsenbord dansen?

De file blijft gelijk.

En waarom controleer je overal error-codes, behalve bij die laatste fwrite?

Omdat het toch 0 bytes zijn die geschreven worden. Dan is er geen verschil met een foutcode want die is ook nul.

En als je bijvoorbeeld toch data schrijft (en dus niet 0 bytes), komt die data dan op die plek in de file te staan?

Ja, in dat geval komt de tekst in de buffer op die plek te staan.

Overigens zie ik nergens het door jouw gewenste gedrag in de ISO C (99) spec gedocumenteerd staan.

Het is toch een "bekende" methode om files in te korten. File pointer ergens neerzetten, nul bytes schrijven en dan closen. Dan zou de file tot op die plek ingekort moeten worden. Ik weet dat het moet kunnen. Ik heb het ooit in een ver verleden gebruikt in antivirus programmaatjes. Dan moest zo'n file zijn originele lengte terug krijgen. Maar daar heb ik hier nu geen toegang toe.

[hneel]

.oisyn schreef op dinsdag 17 juli 2007 @ 15:35:
[...]


Dus als je implementation dat support, zul je 'm sowieso als text moeten openen.

"r+b", "r+t", "r+". Het maakt allemaal geen verschil...

[Verwijderd]

.oisyn schreef op dinsdag 17 juli 2007 @ 15:18:
sinaasappelsap: Misschien moet je zelf eens naar die openmodes kijken, aangezien daar staat dat r+ voor reading én writing is, zonder dat er getruncate wordt (wat je ook niet wilt, aangezien je dan een lege file overhoudt als je niets schrijft)

Ik begreep hieruit dat dat juist de bedoeling is, vandaar? Blijkbaar niet..

[igmar]

Omdat een 0 byte write zover ik weet een noop is. Ik zie zelf het nut van 0 bytes schrijven ook niet in. Kun je geen ftruncate() gebruiken ?

Op Linux en FreeBSD is het inderdaad een noop.

[ Voor 15% gewijzigd door igmar op 17-07-2007 15:55 ]

[igmar]

Verwijderd schreef op dinsdag 17 juli 2007 @ 15:47:
Ik begreep hieruit dat dat juist de bedoeling is, vandaar? Blijkbaar niet..

Hij wil 'm truncaten vanaf byte 0x100. Met die open modes gooi je de hele file wel, wat ie dus niet wil.

[hneel]

igmar schreef op dinsdag 17 juli 2007 @ 15:50:
Omdat een 0 byte write zover ik weet een noop is. Ik zie zelf het nut van 0 bytes schrijven ook niet in.

Het zal toch niet zo zijn dat de compiler dat dan weg "optimaliseert"?
Zeg me dat het niet zo is. Zeg me dat het niet waar is.

Kun je geen ftruncate() gebruiken ?

Die functie ken ik niet. En mijn compiler ook niet. Het is trouwens Borland C++ 5.02 wat ik hier voor gebruik.

[.oisyn]

hneel schreef op dinsdag 17 juli 2007 @ 15:38:
Het is toch een "bekende" methode om files in te korten. File pointer ergens neerzetten, nul bytes schrijven en dan closen. Dan zou de file tot op die plek ingekort moeten worden. Ik weet dat het moet kunnen. Ik heb het ooit in een ver verleden gebruikt in antivirus programmaatjes. Dan moest zo'n file zijn originele lengte terug krijgen. Maar daar heb ik hier nu geen toegang toe.

Dat je het ooit, in een ver verleden, zo gedaan hebt, wil niet meteen zeggen dat alle C implementaties zo werken.

hneel schreef op dinsdag 17 juli 2007 @ 15:56:
[...]


Het zal toch niet zo zijn dat de compiler dat dan weg "optimaliseert"?
Zeg me dat het niet zo is. Zeg me dat het niet waar is.

Natuurlijk optimaliseert je compiler dat niet weg. Maar wellicht is de implementatie van fwrite gewoon:

C:

int fwrite(void * buffer, int c, int e, FILE * f)
{
    if (!c || !e)
        return 0;

    // do write, etc.
}

Anyway, je kan natuurlijk de byte op plek 0xff inlezen en die opnieuw uitschrijven op die plek, als dat idd de issue blijkt.

[ Voor 5% gewijzigd door .oisyn op 17-07-2007 16:00 ]

[SchizoDuckie]

code:

 echo. > filename.txt

Waarom daarvoor een hele executable programmeren

[.oisyn]

Lees je überhaupt wel?