The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,350 other followers

Reminiscence of the past: Delphi I/O error 131

Posted by jpluimers on 2013/08/06

I was called by a client that didn’t want to do maintenance on an old Delphi application, but wanted to get dir of an I/O Error 131:

I/O Error 131: ERROR_NEGATIVE_SEEK

MessageText: An attempt was made to move the file pointer before the beginning of the file.

Tough luck: psychic powers told me someone is using an unsigned 32-bit integer to access a file using traditional style Assign/Reset/Seek/Read/Close patterns that Delphi kept as intrinsic routines for Turbo Pascal backward compatibility, and that file has grown over 2 gigabyte in size.

I quickly found an import file had grown over the 2 gigabyte, so this was indeed the case.

The original developers didn’t do the file access using the 64-bit Seek/Position of the TStream descendant TFileStream.

Too bad, as now someone has to dig through the mothballs to find the sources (if they survived 3 different version control system switches), create a working development environment, and fix the bug.

Another instance where technical debt in IT raises its ugly head and the compound interest is really expensive.

–jeroen

via: erikmartin.com – IO Errors in Delphi.

14 Responses to “Reminiscence of the past: Delphi I/O error 131”

  1. Joseph said

    You’ve had to go and remind me of one of the things that drive me crazy about the current state of Delphi, the fact that there are now at least six ways to read/write files in the standard library, all with their own quirks/set of features. :-( Combined with a lot of Delphi pages out there that haven’t been updated since 1998, and it’s quite a mess and a hazard for those who would try to learn the language today.

    Delphi’s standard library needs a good cleaning out to remove the cobwebs, along with a good refactoring (for instance, “Pos” and “PosEx” – once Delphi had optional parameters, there was no need for separate functions). Hopefully the move to a new compiler will be the motivation for Embarcadero to finally due that.

    • jpluimers said

      I totally agree with you (and I’d even go further: choose a naming and abbreviation convention, then stick to it and deprecate all old stuff), but I don’t think they will do anything with cobwebs.
      And don’t get me started on zero-based strings…
      –jeroen

  2. I just checked in my Delphi “museum” and my recollection was accurate. TStream.Size/Position and attendant Seek parameters were “LongInt” (i.e. 32-bit) up to and including Delphi 5. Delphi 6 introduced the Int64 Size/Position and the overload for Seek.

    • jpluimers said

      I was only 1 Delphi version off then (:

      • Yep, but did anyone ever really use 6 ? So allowing for UVR (Usable Version Rounding), you were spot on. :)

        • jpluimers said

          (:
          The only old version I still use is 2007 for projects not yet migrated to Unicode. And boy, I miss a lot of things in that one.
          Had to go back to Delphi 5 a while back for a project: that was a nightmare!

        • Jon Robertson said

          The company I work for full-time used Delphi 6 exclusively for eight years. We started migrating our project to Delphi 2009 but were not able to take it to production status until Delphi XE due to bugs in the new DataSnap. We still do a little maintenance on the Delphi 6 version of our product. ;) Long live Delphi 6. Delphi 7 was good too, but honestly it didn’t provide us anything that Delphi 6 didn’t have.

          • jpluimers said

            Good to hear from you! Too bad the DelphiLive conferences weren’t continued.

            For me, Delphi 7 was what Delphi 6 should have been. Less bugs, faster IDE, better SOAP support, better compiler warnings, and ModelMaker included (I still love their tools).

            There is more, I had to look here to remember some of the details: http://edn.embarcadero.com/article/28980

      • KMorwath said

        Yes, getting back to D5 is a nightmare, the IDE is soooooo faaaaaaast :) Of course there’s a lot missing also, but the Galileo IDE is making the great scientist soul trying to find a way to sue Embarcardero for using his name for such a crappy product. It’s true that Galileo is the father of experimental method, but that doesn’t mean they should experiment on customers – and never fix issues!

  3. Your psychic powers might have jumped a little too far in drawing their conclusion.

    32-bit offset used ? Yes. But assumptions about how that 32-bit access was arrived at are unfounded. That very StackOverflow question you link to explains how even using TStream can inadvertently result in a 32-bit seek, even if a 64-bit value is diligently specified by the caller.

    And that assumes that the Delphi version in question had Int64 support for Seek/Position in TStream. I have a hazy recollection that this was not always the case, though you don’t specify how old the old version of Delphi involved is so one can’t say whether this is possible, even if my recollection is correct (and it may well not be).

    • jpluimers said

      The psychic was OK: it was indeed such a seek.

      I mentioned `TFileStream`, which was one of the stream classes implementing a 64-bit Seek. I did know that `TMemoryStream` in x86 land didn’t have the `Int64` based `Seek` methods overloaded.

      Your memory is OK though and your psychic powers too: when Delphi didn’t have `Int64`, the `Int64` overloads of Seek did not exist (even though they could have done a `Comp` overload). I traced down the original version this code was written in was pre-Delphi 7. And I’m almost certain that both `Int64` and those `Seek` overloads were introduced in Delphi 7.

      I will check my source archive on this later.

    • KMorwath said

      At least if they had used TStream it would been easier to fix it, maybe moving the code to a later release with 64 bit file support. The old file interface has lot of issues, and is not thread safe. Why people insist on using it is beyond my understanding.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: