I got a strange error while compiling, saying that fpc couldn't open the "fpc.cfg" file (sorry lost the exact wording)

The file definitely was/is there. And on repeated compilation all worked fine.

Only thing I can think off: I was compiling to different projects. The projects where completely separate, only the same compiler was used. I've done that often, and never had an issue.
But *if* fpc does lock the fpc.cfg file exclusively ( for a very short time only, e.g. just open+lock, read, close), then there is the slim chance of a conflict, and this error could be explained.

Anyone any idea?

Martin

Martin wrote

But *if* fpc does lock the fpc.cfg file exclusively ( for a very short time only, e.g. just open+lock, read, close), then there is the slim chance of a conflict, and this error could be explained.

FPC opens it as a regular text file using a regular assign/reset. I don't think that will result in exclusive access. It also checks for its existence using sysutils.fileexists, but I doubt that one asks for exclusive access either.

Jonas

Jonas Maebe wrote

On 28 Aug 2010, at 01:07, Martin wrote: > But *if* fpc does lock the fpc.cfg file exclusively ( for a very short time only, e.g. just open+lock, read, close), then there is the slim chance of a conflict, and this error could be explained. FPC opens it as a regular text file using a regular assign/reset. I don't think that will result in exclusive access. It also checks for its existence using sysutils.fileexists, but I doubt that one asks for exclusive access either.

Afaik uing assign/reset using exclusive lock on windows. Lazarus did use them for logfiles, and you couldn't open the lockfile (fro tailing) because of that.

Martin

In our previous episode, Jonas Maebe said:

Doesn't that depend on filemode? I see a lot of places in the compiler where it is read/changed/preserved:

comprsrc.pas:  oldfmode:=Filemode;
comprsrc.pas:  Filemode:=0;
comprsrc.pas:  Filemode:=oldfmode;
cstreams.pas:  oldfilemode : byte;
cstreams.pas:      oldfilemode:=filemode;
cstreams.pas:      filemode:=$40 or Mode;
cstreams.pas:      filemode:=oldfilemode;
finput.pas:        ofm:=filemode;
finput.pas:        filemode:=0;
finput.pas:        filemode:=ofm;
impdef.pas:  OldFileMode:longint;
impdef.pas:  OldFileMode:=filemode;
impdef.pas:   filemode:=0;
impdef.pas:   filemode:=OldFileMode;
ppu.pas:  ofmode:=filemode;
ppu.pas:  filemode:=$0;
ppu.pas:  filemode:=ofmode;
ppu.pas:    ofm:=filemode;
ppu.pas:    filemode:=0;
ppu.pas:    filemode:=ofm;

None of them in options. So there could be something to it, specially since it is so early in the startup.

Hmm,

I did a quick writeln(filemode) just before the config file was opened, and it printed 2, read/write (the default.

I thought that was only for regular files, not for text files (since if you open a regular file using reset, you can still write to it, while that's not the case for text files).

Jonas

In our previous episode, Hans-Peter Diettrich said:

We still have to support the filemode var out of compatibility.

So I'm not exactly sure what you are proposing.

Do you mean you want a kind file I/O wrappers somewhere to avoid this in new code? Then there is no reason to use mutate the existing routines, just write a new unit.

Doesn't that depend on filemode? I see a lot of places in the compiler where it is read/changed/preserved:

[...]

None of them in options. So there could be something to it, specially since it is so early in the startup.

IMO we should add an (optional?) filemode parameter to the old style file procedures, so that every file can be opened with the appropriate settings and without affecting other files. Just like in TFileStream...

The default mode should not lock any file, at least for read(only) access.

DoDi