(Solved): TStringList.LoadFromFile fails

[Bart]

I don't see that he mentioned Delphi.
He said that that his old application, which is written in C#, opens it without error.

My bad.
Sorry.

Bart

[Birger52]

Well - guess it's OK, to get all the aspects out in the open.
I haven't used Delphi since it was a Borland product - version 2 if memory servers (it might not!) back in the 80's.

Noticed tho, that GetLastOSError return 32 when trying to open the file with AssignFile or FileOpen.
SysErrorMessage translates this to "File already open" (in Danish here tho...) while
TStringList.LoadFromFile and TFileStream.Create(..., fmOpenRead or fmShareDenyWrite) returns 6 for GetLastOSError, which SysErrorMessage translates to Invalid Handle.

So it seems, that even if it IS compatible with Delphi, there are internal inconsistencies...
Essentially, the FileStream versions returns an incorrect errorcode, when creating the stream fails.

[Bart]

So it seems, that even if it IS compatible with Delphi, there are internal inconsistencies...
Essentially, the FileStream versions returns an incorrect errorcode, when creating the stream fails.

It's the OS that reports this error, we don't make it up on our own 

Bart

[rvk]

Noticed tho, that GetLastOSError return 32 when trying to open the file with AssignFile or FileOpen.
SysErrorMessage translates this to "File already open" (in Danish here tho...) while
TStringList.LoadFromFile and TFileStream.Create(..., fmOpenRead or fmShareDenyWrite) returns 6 for GetLastOSError, which SysErrorMessage translates to Invalid Handle.
Essentially, the FileStream versions returns an incorrect errorcode, when creating the stream fails.

Weird. For me TStringList.LoadFromFile also returns 32 when I try to open a file which is already open (in LibreOffice).

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. var
3.   sl: TStringList;
4. begin
5.   sl := TStringList.Create;
6.   try
7.     try
8.       sl.LoadFromFile('c:\temp\test.ods');
9.     except
10.       on E: Exception do Showmessage(E.Message + #13 + GetLastOSError.ToString);
11.     end;
12.   finally
13.     sl.Free;
14.   end;
15. end;

I imagine the exception isn't (or IS) handled somewhere and the invalid handle is used in a further process.
But a LoadFromFile() shouldn't do that on it's own.

[winni]

Well - guess it's OK, to get all the aspects out in the open.
I haven't used Delphi since it was a Borland product - version 2 if memory servers (it might not!) back in the 80's.

Noticed tho, that GetLastOSError return 32 when trying to open the file with AssignFile or FileOpen.
SysErrorMessage translates this to "File already open" (in Danish here tho...) while
TStringList.LoadFromFile and TFileStream.Create(..., fmOpenRead or fmShareDenyWrite) returns 6 for GetLastOSError, which SysErrorMessage translates to Invalid Handle.

So it seems, that even if it IS compatible with Delphi, there are internal inconsistencies...
Essentially, the FileStream versions returns an incorrect errorcode, when creating the stream fails.

The dead crawl oßut of the grave....

IOerror 32 was "invdented" with win 3.1 and means "sharing file violation".
I have not seen this for decade.

And the IOerrors come from the OS, not from fpc/Lazarus.

So the last version managed to wakde up the "dead" IOerror.

Winni

[rvk]

The dead crawl oßut of the grave....
IOerror 32 was "invdented" with win 3.1 and means "sharing file violation".
I have not seen this for decade.
And the IOerrors come from the OS, not from fpc/Lazarus.
So the last version managed to wakde up the "dead" IOerror.

System error 6 and System error 32 have nothing to do with the old IOError from win 3.1.

They are just System Errors defined by Windows...
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes--0-499-

My snippet really gives System Error 32 which means ERROR_SHARING_VIOLATION (32 / 0x20) The process cannot access the file because it is being used by another process.

[winni]

Bravo rvk!

Systen Error 32 has nothing to do with System Error 32!!!!

ERROR_SHARING_VIOLATION  = IOError 32 was introduced in Win 3.1 when the first file servers appeared in the small companies  - mosty Novell Netware 3.x .

Winni

[rvk]

The dead crawl oßut of the grave....
...
So the last version managed to wakde up the "dead" IOerror.

Your quote... is that the last version managed to wake up the dead IOerror.

I only tried to show that System Error 32 was there all along.
I have them regularly.

So it's nothing new to 'the last version'.

Maybe I expressed myself wrong... but these System Errors are NOTHING new (or old). They've been there all along.