Results 1 to 11 of 11

Thread: I/O error 103 bij AssignFile?

  1. #1
    Member DaSteelMan's Avatar
    Join Date
    Apr 2004
    Location
    Eys (LimboLand)
    Posts
    95

    Question I/O error 103 bij AssignFile?

    Hallo,

    Sinds mijn desktop is vervangen voor een exemplaar met Windows 10 (ja, nu al...) krijg ik tijdens debuggen in Delphi 10.1 Berlin de foutmelding 'I/O error 103' bij het toekennen van een bestandsnaam op de volgende regel:
    Code:
    AssignFile(EPWInFile,sXE_EPWInFile);
    Hetzelfde project in Delphi XE2 kan wel zonder problemen gedebugged worden. Onder Windows 7 heb ik hier nooit last van gehad...


    Heeft iemand een tip?
    Achtbanen!
    Soms ben je er helemaal van ondersteboven...

  2. #2
    Counting your refs
    Join Date
    Feb 2002
    Location
    Lage Zwaluwe
    Posts
    2,064
    Spannend, weet je *zeker* dat dat de regel is? Mijn beeld is dat AssignFile zelf niets doet, behalve het toekennen van de bestandsnaam aan de filehandle. IO volgt pas bij de eerstvolgende reset/rewrite, toch?

    M'n eerste verdachte zou Windows Defender zijn (of een eventuele andere anti-virus oplossing die je hebt draaien), speelt het ook als die uit staat? Naar/van welke locatie probeer je te lezen/schrijven, nog een bijzondere plek op schijf?

  3. #3
    Member DaSteelMan's Avatar
    Join Date
    Apr 2004
    Location
    Eys (LimboLand)
    Posts
    95
    Hallo Paul-Jan,

    Het is definitief die regel.
    - Op de volgende regel staat Exit...
    - Voorgaande regels bevatten alleen het initialiseren van Integers.
    - TextFile en bestandsnaam zijn globale variabelen

    Lijstje van 103: Reported by CloseFile, Read Write, Seek, Eof, FilePos, FileSize, Flush, BlockRead, or BlockWrite. Hier staat AssignFile niet bij...

    Als het de virusscanner is zal deze toch ook zijn werk doen bij Delphi XE2?
    Ik heb de vraag wel neergelegd bij onze ICT afdeling. Zelf kan ik de virusscanner niet disablen (Symantec Endpoint Protection, Managed).

    Het bestand staat op de harde schijf van de desktop: D:\Temp\SDR-BB-6.in. Niets speciaals aan. Heb nog getest met D:\test_Delphi\SDR-BB-6.in maar maakt niets uit. Het is een plaint-text document.


    Bedankt voor het meedenken!
    Achtbanen!
    Soms ben je er helemaal van ondersteboven...

  4. #4
    Het kan ook zijn dat je ergens vergeten bent de ioresult uit te lezen na een {$I+}. Als je dan nog een ioresult in de lucht hebt hangen zou die best in assignfile getriggered kunnen worden.

    Maar goed. Zonder code kunnen we niet veel.

  5. #5
    Member DaSteelMan's Avatar
    Join Date
    Apr 2004
    Location
    Eys (LimboLand)
    Posts
    95
    Code:
    {$I-}
        AssignFile(EPWInFile,sXE_EPWInFile);
    {$I+}
    Door niet naar I/O error op de betreffende regel te kijken loopt de debug door zonder verdere foutmeldingen. Er is dus definitief iets aan de hand met AssignFile.

    @rvk: je bericht overlapte mijn reactie...
    Ik heb de boel al zover gesloopt dat er geen andere bestandsacties zijn geweest. Alle {$I+} had ik al weggehaald.
    Achtbanen!
    Soms ben je er helemaal van ondersteboven...

  6. #6
    Verwijder alle {$I-} eens. Ik heb echt het vermoeden dat het probleem helemaal ergens anders in je code zit. En dat komt eruit bij de eerstvolgende keer dat je die ioresult uitleest op een andere plaats. (Of in + status een systemcall doet zoals assignfile)

    Dit is een veelvoorkomend probleem. Je vergeet ergens een ioresult uit te lezen en dan komt die foutmelding op een hele andere plaats opeens uit je code.

    Controleer of je achter alle {$I-} netjes de ioresult uitleest. Als je er een vergeten bent zal daar je probleem liggen. En dat kan dus ook helemaal ergens anders in je code zitten.

  7. #7
    Fornicatorus Formicidae VideoRipper's Avatar
    Join Date
    Mar 2005
    Location
    Vicus Saltus Orientalem
    Posts
    5,245
    Quote Originally Posted by DaSteelMan View Post
    Door niet naar I/O error op de betreffende regel te kijken loopt de debug door
    Dat is ook de hele bedoeling van {$I-}: je zet daarmee error-checking uit (niet echt, maar je code geeft geen foutmelding bij uitvoeren).
    Daarom moet je na het opnieuw aanzetten {$I+} ook altijd IOResult uitlezen: als het goed is heeft deze na het aanzetten als waarde 103.

    Je kunt het vergelijken met een try...except...end waarbij je tussen except en end helemaal niets doet (en de exception inslikt).
    Dat wil niet zeggen dat er niets verkeerd ging.
    TMemoryLeak.Create(Nil);

  8. #8
    Member DaSteelMan's Avatar
    Join Date
    Apr 2004
    Location
    Eys (LimboLand)
    Posts
    95
    Okay...

    Het wordt al duidelijker. Ik heb IOResult opgevraagd vóór AssignFile, deze staat al op 103.
    Ik heb in de hele code nergens {$I-} staan, ook niet bij de debugger exceptions. Anders kwam hij natuurlijk ook niet naar voeren bij de AssignFile...

    Nu op zoek waar IOResult wordt gezet. En natuurlijk wie de exception inslikt.

    Bedankt!
    Achtbanen!
    Soms ben je er helemaal van ondersteboven...

  9. #9
    Member DaSteelMan's Avatar
    Join Date
    Apr 2004
    Location
    Eys (LimboLand)
    Posts
    95

    Lightbulb FYI: Opgelost

    Heb me echt de [Krachtterm] gezocht...

    Ik heb het project helemaal uitgekleed tot er echt maar een paar regels code overbleven. Deze regels werden niet eens uitgevoerd omdat ik iedere procedure met Exit; begon.
    Toen ik de bestanden in een andere folder bij elkaar had staan om hier te plaatsen nog even getest. Resultaat: geen fout tijdens debuggen?

    In het DSK bestand vond ik toen onder de sectie [Watches]: Watch7='Eof(EPWInFile)',256,0,18,1,1,'Watches',1

    Oops!
    Dus zodra het project in debug gaat wordt er een I/O error gegenereerd, zonder dat er enige code is uitgevoerd!

    Achteraf heel logisch, maar tijdens het zoeken zeker niet...


    De groentjes!
    Achtbanen!
    Soms ben je er helemaal van ondersteboven...

  10. #10
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,701
    Wel, het is op zicht wel een interessante observatie. Het is nieuw voor mij dat sideeffects van debug expressies zo je programma kunnen beïnvloeden.

  11. #11
    Haha, ja, inderdaad, heel logisch. Zelf nooit een eof() in de watches gezet maar ik kan me voorstellen dat je je daar helemaal suf op kan zoeken

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (0 members and 2 guests)

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •