Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Jonas Maebe]

James Richters wrote:
> I have a freepascal Windows console application that I recently ported
> over from DOS Turbo Pascal.   I am have a small settings file that I
> write to disk that keeps getting corrupted.  It happens only
> occasionally, but it’s always this one file, no others.Do I need to
> do something specific to force windows to write the file to disk and not
> have it in some kind of cache or buffer?   I am using the following code
> to write the file:

This reminds me of a bug report from a couple of years back, where
someone else had a somewhat similar weird issue under Windows:
http://bugs.freepascal.org/view.php?id=27670

Do you happen to use Flexraid as well?


Jonas
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Tomas Hajny]

On Tue, February 21, 2017 22:12, James Richters wrote:


Hello James,

> I have a freepascal Windows console application that I recently ported
> over from DOS Turbo Pascal.   I am have a small settings file that I write
> to disk that keeps getting corrupted.  It happens only occasionally, but
> it’s always this one file, no others.Do I need to do something
> specific to force windows to write the file to disk and not have it in
> some kind of cache or buffer?   I am using the following code to write the
> file:
>
>Assign(BitFile,'BitSave.pax');
>ReWrite(BitFile);
>WriteLn(BitFile,XADJ:1:8);
>WriteLn(BitFile,YADJ:1:8);
>WriteLn(BitFile,ZADJ:1:8);
>WriteLn(BitFile,WADJ:1:8);
>WriteLn(BitFile,AADJ:1:8);
>WriteLn(BitFile,TADJ:1:8);
>WriteLn(BitFile,VADJ:1:8);
>WriteLn(BitFile,UADJ:1:8);
>WriteLn(BitFile,CurrentTool);
>WriteLn(Bitfile,P_Value[4]);
>Close(BitFile);
>
> The above only happens when I make a change to one of the settings, and
> the system is never having any issue at that time, yet upon occasion I
> will have an error opening the file and when I inspect it, it’s just a
> long string of [nul].   I am not leaving the file open, I’m assigning it,
> writing to it, then closing it, so there should be no opportunity for data
> to be lost.  I am having the same issue on about 8 different computers,
> most of which are running solid state hard drives. It’s always just this
> one file that is affected, nothing else.  No other process ever uses this
> file, so it must be my freepascal program that is leaving the file in a
> vulnerable state.

It's difficult to find out possible reasons without fully compilable
source. If I should guess, I would check the types of the variables used
for writing and also make sure that the content of those variables isn't
overwritten in memory (i.e. even before they're written to the file). In
particular, if your variables are strings and you compiled the source
(originally written for Turbo Pascal, i.e. using shortstrings) e.g. with
{$H+}, or in a compiler mode using ansistrings or
widestrings/unicodestrings by default _and_ the original source modified
the strings in a non-standard way, you might overwrite the content of
those variables.

BTW, what exactly is the error you get when opening the file?


> My understanding was the Close(file); would save the file all the way to
> disk and flush any buffers that were holding it, but I’m wondering if that
> was only true for DOS and there is some other windows cache or buffer that
> also needs to be instructed to flush to truly save the file all the way to
> disk and close it.

Your understanding is correct, nothing else should be necessary.

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FreePascal Windows - Force files to write to disk

[James Richters]

I have a freepascal Windows console application that I recently ported over 
from DOS Turbo Pascal.   I am have a small settings file that I write to disk 
that keeps getting corrupted.  It happens only occasionally, but it’s always 
this one file, no others.Do I need to do something specific to force 
windows to write the file to disk and not have it in some kind of cache or 
buffer?   I am using the following code to write the file:

 

 

   Assign(BitFile,'BitSave.pax');

   ReWrite(BitFile);

   WriteLn(BitFile,XADJ:1:8);

   WriteLn(BitFile,YADJ:1:8);

   WriteLn(BitFile,ZADJ:1:8);

   WriteLn(BitFile,WADJ:1:8);

   WriteLn(BitFile,AADJ:1:8);

   WriteLn(BitFile,TADJ:1:8);

   WriteLn(BitFile,VADJ:1:8);

   WriteLn(BitFile,UADJ:1:8);

   WriteLn(BitFile,CurrentTool);

   WriteLn(Bitfile,P_Value[4]);

   Close(BitFile); 

 

The above only happens when I make a change to one of the settings, and the 
system is never having any issue at that time, yet upon occasion I will have an 
error opening the file and when I inspect it, it’s just a long string of [nul]. 
  I am not leaving the file open, I’m assigning it, writing to it, then closing 
it, so there should be no opportunity for data to be lost.  I am having the 
same issue on about 8 different computers, most of which are running solid 
state hard drives. It’s always just this one file that is affected, nothing 
else.  No other process ever uses this file, so it must be my freepascal 
program that is leaving the file in a vulnerable state.

My understanding was the Close(file); would save the file all the way to disk 
and flush any buffers that were holding it, but I’m wondering if that was only 
true for DOS and there is some other windows cache or buffer that also needs to 
be instructed to flush to truly save the file all the way to disk and close it.

 

Thanks for any advice on this

 

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] pyacc and using hexadecimals in the code

[Darius Blaszyk]

Hi all,

I would like to use hexadecimal values in a pyacc script. However, when
doing so pyacc thinks I am using a rule assign (or whatever the correct
term is) eg $$ := $1 as opposed to writeln(yyoutput, $76);.

Is this a shortcoming of pyacc, or do I need to escape the dollar sign
in a specific way? Any help from pascal lex/yacc experts is appreciated!

Regards, Darius___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal