Whoa!!! Can this be cross linked files?

[Rex]

I've run scandisk on an old HP/Win98 machine. Comes up with no
problems. I ran it because I suspected cross linked files. Here's
why.

I sell an application that runs a cool java database called hsql.
Long story short a user called me one day and said the database
wouldn't start. Lots of troubleshooting later I found the problem -
junk appended to the end of the main datafile corrupting it. The junk
appeared to be part of another file on her system, almost as if
windows didn't know where my data file ended. Cut the junk out of the
file and the database starts fine. Problem repeats though randomly
over the course of the next week each time with different garbage from
her system showing up.

Positive it's not my program. There are hundreds of installations of
it out there with the same exact build (including one on another
identical HP machine in this customer's office) and never has this
problem been seen. The user has also reported other random errors on
this particular machine including office back-up utilities choking on
it.

Take a look at the end of the datafile in the last case of the error
and tell me if you think this looks like crosslinked files.

Here's what the divide at the end of the data file looked like (name
and address in the record shown here modified to protect the
innocent)...

DELETE FROM CLIENT WHERE ID=288
INSERT INTO CLIENT VALUES(288,'Smith,
Angie',NULL,'Larro',NULL,'Angie',NULL,NULL,NULL,NU LL,NULL,NULL,NULL,'204
N Tarpid Blvd',NULL,'Mayberry','NJ','08112-','',NULL,'','(',NULL,'','(',NULL,'','(',NULL,'',N ULL,NULL,NULL,NULL,NULL,'House
Account','11/10/2004',false,NULL,false)
COMMIT
SET AUTOCOMMIT TRUE
SET AUTOCOMMIT FALSE
COMMIT
SET AUTOCOMMIT TRUE
SET AUTOCOMMIT FALSE
COMMIT
SET AUTOCOMMIT TRUE



......All of that stuff is normal. We see it all the time....

......This stuff that follows though is not and goes on for hundreds of
lines. The "NextPart_000" stuff makes me think it's part of some
email message or something....



------=_NextPart_000_0005_01C4C728.05DFF880--
v?mô 
‹Eô)…ÿÿÿ€}·ÿuÆE· j ÿuìÿuüÿS;EìtÿuðÿuüÿuSèèÈýÿf¸
ƒÄén
hø
?…¸þÿÿPÿuüÿS=ø tÿuðÿuüÿuSè´Èýÿf¸
ƒÄé:
j
WÿuüÿS;ÇtÿuðÿuüÿuSèŒÈýÿf¸
ƒÄé

j(?E°PÿuüÿSƒø(tÿuðÿuüÿuSè`Èýÿf¸
ƒÄéæ ‹EÀ‹U+E¸‰Eô=
r¸

‰Eøf3Àƒ}ø vf@Æ ·ÈB;Mørò‹E¸j
EèÿuèÿuüÿS;EètÿuðÿuüÿuSèýÇýÿf¸

ƒÄéƒ ‹Eô=
r¸
P‰EøÿuÿuüÿS;Eøu4‹Eø)Eôu×VÿuüSèîÇýÿƒÄÿuðf=

ÿuüÿuSöè¦ÇýÿfFƒÄf‹Æë.ÿuðÿuüÿuSè?Çýÿf¸
ƒÄëÿuðÿuüÿuSèuÇýÿf¸
ƒÄ_^[‹å]Ãì ÆD$ÍÆD$ƒÆD$‹ÆD$åÆD$ÆD$]ÆD$MSVWU?D$?L$‹|$<P‹t$8QÆD$3ÊÆD$4
ÆD$5 WVèÒÆýÿƒÄf…Àt f¸
éò
j h½[
ÿt$ÿV=½[
tÿt$ÿt$WVèàÆýÿf¸

ƒÄéÂ
?D$jPÿt$ÿVƒøtÿt$ÿt$WVè²Æýÿf¸
ƒÄé"

f?|$ZMt$f?|$MZtÿt$ÿt$WVè…Æýÿf¸ ƒÄég
j hÙ[
ÿt$ÿV=Ù[

tÿt$ÿt$WVèUÆýÿf¸
ƒÄé7
?D$jPÿt$ÿVƒøtÿt$ÿt$WVè'Æýÿf¸

ƒÄé
ÿt$·D$½[
‰D$ÿV‰D$ ƒøÿuÿt$ÿt$WVèîÅýÿf¸
ƒÄéÐ
fÇD$MM‹l$ +l$?D$$j
PUÿt$$ÿt$Pÿt$(Vè¬ÆýÿƒÄ‹Øƒûÿt;j Sÿt$ÿV;Ã…" ?D$jPÿt$ÿVƒø…"
?C
‹l$ +è‰D$ƒûÿu¡‹D$ -½[
Pj h½[
ÿt$Lÿt$$Vè»Åýÿf‰D$*ƒÄf…Àuh½[

ÿt$VèiÅýÿf‰D$ƒÄÿt$fƒ|$
ÿt$WÛVfCèÅýÿf‹ÃƒÄ]_^[ƒÄ
Ãÿt$ÿt$WVèûÄýÿf¸
ƒÄëàÿt$ÿt$WVèãÄýÿf¸

ƒÄëÈU‹ìƒì<S?EÜV?MàW‹uPQÿuVèzÄýÿƒÄf…Àt f¸
éá
?EÈ‹}PWÿuàVè÷æÿÿƒÄf…ÀtÿuÜÿuàÿuVè„Äýÿf¸ ƒÄé*
ÿuàÿVf‹W‰EÄf‹Gf‰Eæf‹_f‰Eêf‹G2f‰]ô·_"f‰Eè]ȸ
ŠMèÓè·Êf@‰MÔf‰Eìj ·G$EȉEØ?DËøP‰EðÿuàÿV;EðtÿuÜÿuàÿuVèÄýÿf¸

ƒÄé- j?EîPÿuàÿVƒøtÿuÜÿuàÿuVèØÃýÿf¸
ƒÄé
 ŠMèj
·UîÓâ·Eæ?L
Q‰MÐÿuàÿV;EÐtÿuÜÿuàÿuVè›Ãýÿf¸
ƒÄéÄ
j?EæPÿuàÿVƒøtÿuÜÿuàÿuVèoÃýÿf¸
ƒÄé˜ f‹Eæj
f‹Mìf‰Gf)O:ÿuÈÿuàÿV;EÈtÿuÜÿuàÿuVè4Ãýÿf¸
ƒÄé]
j@WÿuàÿVƒø@tÿuÜÿuàÿuVèÃýÿf¸
ƒÄé4 j
SÿuàÿV;ÃtÿuÜÿuàÿuVèãÂýÿf¸
ƒÄé fÇEðÿÿfÇEþ fƒ}ô „›
jWÿuàÿVƒø…¸ f‹f‰Eúf9Eîwgsf‹Eðf;Eúvf‹Eúf‰Eðf‹Eúf+Eìf‰ë



blah blah blah....

[Jeff Richards]

This is not necessarily crosslinked files. It could simply be that the
system is allocating space to the file, but whatever data is being written
to the newly allocated space (if any) is not getting saved to disk. The
file is valid as far as the file system is concerned. The garbage is
whatever happened to be on disk in the newly allocated sectors. I would
look at a cache setting, as it seems that your application thinks the file
contains more data than it really does. Can you confirm if any data is
missing from the file after it becomes corrupted like this (data that should
have been written to disk in the new sectors)? I would also look at the
process by which the file is being closed, as the application may require a
close command to truncate the file at the actual end of data (instead of end
of physical file).
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Rex" > wrote in message
om...
> I've run scandisk on an old HP/Win98 machine. Comes up with no
> problems. I ran it because I suspected cross linked files. Here's
> why.
>
> I sell an application that runs a cool java database called hsql.
> Long story short a user called me one day and said the database
> wouldn't start. Lots of troubleshooting later I found the problem -
> junk appended to the end of the main datafile corrupting it. The junk
> appeared to be part of another file on her system, almost as if
> windows didn't know where my data file ended. Cut the junk out of the
> file and the database starts fine. Problem repeats though randomly
> over the course of the next week each time with different garbage from
> her system showing up.
>
> Positive it's not my program. There are hundreds of installations of
> it out there with the same exact build (including one on another
> identical HP machine in this customer's office) and never has this
> problem been seen. The user has also reported other random errors on
> this particular machine including office back-up utilities choking on
> it.
>
> Take a look at the end of the datafile in the last case of the error
> and tell me if you think this looks like crosslinked files.
>
> Here's what the divide at the end of the data file looked like (name
> and address in the record shown here modified to protect the
> innocent)...
>
> DELETE FROM CLIENT WHERE ID=288
> INSERT INTO CLIENT VALUES(288,'Smith,
> Angie',NULL,'Larro',NULL,'Angie',NULL,NULL,NULL,NU LL,NULL,NULL,NULL,'204
> N Tarpid
> Blvd',NULL,'Mayberry','NJ','08112-','',NULL,'','(',NULL,'','(',NULL,'','(',NULL,'',N ULL,NULL,NULL,NULL,NULL,'House
> Account','11/10/2004',false,NULL,false)
> COMMIT
> SET AUTOCOMMIT TRUE
> SET AUTOCOMMIT FALSE
> COMMIT
> SET AUTOCOMMIT TRUE
> SET AUTOCOMMIT FALSE
> COMMIT
> SET AUTOCOMMIT TRUE
>
>
>
> .....All of that stuff is normal. We see it all the time....
>
> .....This stuff that follows though is not and goes on for hundreds of
> lines. The "NextPart_000" stuff makes me think it's part of some
> email message or something....
>
>
>
> ------=_NextPart_000_0005_01C4C728.05DFF880--
> v?mô 
> > ?.¸þÿÿPÿuüÿS =ø tÿuðÿuüÿuSè´Èýÿf¸
fÄé:
j
> WÿuüÿS;ÇtÿuðÿuüÿuSèOÈýÿf¸
fÄé

> j(?E°PÿuüÿS fø(tÿuðÿuüÿuSè`Èýÿf¸
fÄéæ > ?Eøf3Àf}ø vf@Æ ·ÈB;Mørò >
> fÄéf > ÿuüÿuSöè¦ÇýÿfFfÄf<Æë.ÿuðÿuüÿuSè?Çýÿf¸

> fÄëÿuðÿuüÿuSèuÇýÿf¸
> fÄ_^[<å]Ãfì ÆD$ÍÆD$fÆD$<ÆD$åÆD$ÆD$]ÆD$MSVWU?D$?L$<|$<P > ÆD$5
> WVèÒÆýÿfÄf.Àt f¸
éò
j h½[
ÿt$ÿV=½[
tÿt$ÿt$WVèàÆýÿf¸

> fÄéÂ
?D$jPÿt$ÿVføtÿt$ÿt$WVè²Æýÿf¸
fÄé"

> f?|$ZMt$f?|$MZtÿt$ÿt$WVè.Æýÿf¸ fÄég
j hÙ[
ÿt$ÿV=Ù[

> tÿt$ÿt$WVèUÆýÿf¸
fÄé7
?D$jPÿt$ÿVføtÿt$ÿt$WVè'Æýÿf¸

> fÄé
ÿt$·D$½[
?D$ÿV?D$ føÿuÿt$ÿt$WVèîÅýÿf¸
fÄéÐ
> fÇD$MM > PUÿt$$ÿt$Pÿt$(Vè¬ÆýÿfÄ<Øfûÿt;j Sÿt$ÿV;Ã." ?D$jPÿt$ÿV
> fø."
> ?C
> > ÿt$VèiÅýÿf?D$fÄ ÿt$ff|$
ÿt$WÛVfCèÅýÿf<ÃfÄ]_^[fÄ
> Ãÿt$ÿt$WVèûÄýÿf¸
fÄëàÿt$ÿt$WVèãÄýÿf¸

> fÄëÈU<ìfì<S?EÜV?MàW > ?EÈ<}PWÿuàVè÷æÿÿfÄf.ÀtÿuÜÿuàÿuVè"Äýÿf¸ fÄé*
> ÿuàÿVf > SMèÓè·Êf@?MÔf?Eìj
> ·G$EÈ?EØ?DËøP?EðÿuàÿV;EðtÿuÜÿuàÿuVèÄýÿf¸

> fÄé- j?EîPÿuàÿVføtÿuÜÿuàÿuVèØÃýÿf¸
fÄé
 SMèj
> ·UîÓâ·Eæ?L
Q?MÐÿuàÿV;EÐtÿuÜÿuàÿuVè>Ãýÿf¸
fÄéÄ
> j?EæPÿuàÿVføtÿuÜÿuàÿuVèoÃýÿf¸
fÄé~ f > f > j@WÿuàÿV
> fø@tÿuÜÿuàÿuVè Ãýÿf¸
fÄé4 j
> SÿuàÿV;ÃtÿuÜÿuàÿuVèãÂýÿf¸
fÄé  fÇEðÿÿfÇEþ ff}ô ">
> jWÿuàÿVfø.¸ f<f?Eúf9Eîwgsf >
>
>
> blah blah blah....

[dadiOH]

Rex wrote:
> I've run scandisk on an old HP/Win98 machine. Comes up with no
> problems. I ran it because I suspected cross linked files.
<snip>

My guess is that EOF isn't being determined properly for some reason,
no idea why.

When a file is written, whatever is in the last allocation unit
(extraneous of the file itself) is also written. If the EOF value is
messed up then either the file will appear to be truncated or have
extraneous garbage when viewed.

Been a long time since I messed with assembler but IIRC (pre-Windows)
the end of file was marked with a byte pattern in the file. Must have
been a value in the file's directory entry too. Point is, if you know
Windows file/directory structure you could check EOF with a hex
editor.

--
dadiOH
____________________________

dadiOH's dandies v3.05...
....a help file of info about MP3s, recording from
LP/cassette and tips & tricks on this and that.
Get it at http://mysite.verizon.net/xico

[Ingeborg]

Does the PC automatically switch off at shutdown? Does the user normally
shutdown the system with the database program still open? Maybe the
harddisk get's no time to flush it's cache.

MS has a patch for it.
http://www.microsoft.com/windows98/downloads/contents/WUCritical/q273017/De
fault.asp

[Rex]

If I read you correctly, there would be missing data. All data,
however, is accounted for and is being saved to disk (verified the
number of records using backed up versions of the file and knowlege of
subsequent activity). Moreover, HSQL data files are simply lists of
SQL commands (no binary data) so it makes it real easy to verify that
you have what you think you should have.

As I mention in my post, it really would be unlikely that it is
something within the application. If it were, why would just this one
machine among hundreds of installations exhibit the problem. In the
office in question, next to the machine in question, is another
machine just like it. Same software configuration on same model
machine. No problems there.

I believe the other symptoms experienced on this particular machine,
which I mentioned in my post, point towards some sort of unique
failure on this particular machine. Just can't put my finger on it.
Hard drive scans produce no problems. Memory maybe?

Not critical. They'll get new machines eventually. Just one more of
those wierd mysteries though that I wish I had an answer to. I'd be
the man if I could solve this one :)


"Jeff Richards" > wrote in message >...
> This is not necessarily crosslinked files. It could simply be that the
> system is allocating space to the file, but whatever data is being written
> to the newly allocated space (if any) is not getting saved to disk. The
> file is valid as far as the file system is concerned. The garbage is
> whatever happened to be on disk in the newly allocated sectors. I would
> look at a cache setting, as it seems that your application thinks the file
> contains more data than it really does. Can you confirm if any data is
> missing from the file after it becomes corrupted like this (data that should
> have been written to disk in the new sectors)? I would also look at the
> process by which the file is being closed, as the application may require a
> close command to truncate the file at the actual end of data (instead of end
> of physical file).
> --
> Jeff Richards
> MS MVP (Windows - Shell/User)
> "Rex" > wrote in message
> om...
> > I've run scandisk on an old HP/Win98 machine. Comes up with no
> > problems. I ran it because I suspected cross linked files. Here's
> > why.
> >
> > I sell an application that runs a cool java database called hsql.
> > Long story short a user called me one day and said the database
> > wouldn't start. Lots of troubleshooting later I found the problem -
> > junk appended to the end of the main datafile corrupting it. The junk
> > appeared to be part of another file on her system, almost as if
> > windows didn't know where my data file ended. Cut the junk out of the
> > file and the database starts fine. Problem repeats though randomly
> > over the course of the next week each time with different garbage from
> > her system showing up.
> >
> > Positive it's not my program. There are hundreds of installations of
> > it out there with the same exact build (including one on another
> > identical HP machine in this customer's office) and never has this
> > problem been seen. The user has also reported other random errors on
> > this particular machine including office back-up utilities choking on
> > it.
> >
> > Take a look at the end of the datafile in the last case of the error
> > and tell me if you think this looks like crosslinked files.
> >
> > Here's what the divide at the end of the data file looked like (name
> > and address in the record shown here modified to protect the
> > innocent)...
> >
> > DELETE FROM CLIENT WHERE ID=288
> > INSERT INTO CLIENT VALUES(288,'Smith,
> > Angie',NULL,'Larro',NULL,'Angie',NULL,NULL,NULL,NU LL,NULL,NULL,NULL,'204
> > N Tarpid
> > Blvd',NULL,'Mayberry','NJ','08112-','',NULL,'','(',NULL,'','(',NULL,'','(',NULL,'',N ULL,NULL,NULL,NULL,NULL,'House
> > Account','11/10/2004',false,NULL,false)
> > COMMIT
> > SET AUTOCOMMIT TRUE
> > SET AUTOCOMMIT FALSE
> > COMMIT
> > SET AUTOCOMMIT TRUE
> > SET AUTOCOMMIT FALSE
> > COMMIT
> > SET AUTOCOMMIT TRUE
> >
> >
> >
> > .....All of that stuff is normal. We see it all the time....
> >
> > .....This stuff that follows though is not and goes on for hundreds of
> > lines. The "NextPart_000" stuff makes me think it's part of some
> > email message or something....
> >
> >
> >
> > ------=_NextPart_000_0005_01C4C728.05DFF880--
> > v ?mô
> > > ?.¸þÿÿPÿuüÿS =ø t ÿuðÿuüÿu Sè´Èýÿf¸ fÄ é: j
> > WÿuüÿS ;Çt ÿuðÿuüÿu SèOÈýÿf¸ fÄ é
> > j(?E°PÿuüÿS fø(t ÿuðÿuüÿu Sè`Èýÿf¸ fÄ éæ > ?Eøf3Àf}ø v f@Æ ·ÈB;Mørò >
> > fÄ éf > ÿuüÿu S öè¦ÇýÿfFfÄ f<Æë.ÿuðÿuüÿu Sè?Çýÿf¸
> > fÄ ë ÿuðÿuüÿu SèuÇýÿf¸
> > fÄ _^[<å]Ãfì ÆD$ ÍÆD$ fÆD$ <ÆD$ åÆD$ ÆD$ ]ÆD$ MSVWU?D$ ?L$ <|$<P > ÆD$5
> > WVèÒÆýÿfÄ f.Àt f¸ éò j h½[ ÿt$ ÿV =½[ t ÿt$ ÿt$ WVèàÆýÿf¸
> > fÄ é ?D$ j Pÿt$ ÿV fø t ÿt$ ÿt$ WVè²Æýÿf¸ fÄ é"
> > f?|$ ZMt$f?|$ MZt ÿt$ ÿt$ WVè.Æýÿf¸ fÄ ég j hÙ[ ÿt$ ÿV =Ù[
> > t ÿt$ ÿt$ WVèUÆýÿf¸ fÄ é7 ?D$ j Pÿt$ ÿV fø t ÿt$ ÿt$ WVè'Æýÿf¸
> > fÄ é ÿt$ ·D$ ½[ ?D$ ÿV ?D$ føÿu ÿt$ ÿt$ WVèîÅýÿf¸ fÄ éÐ
> > fÇD$ MM > PUÿt$$ÿt$Pÿt$(Vè¬ÆýÿfÄ <Øfûÿt;j Sÿt$ ÿV ;à ." ?D$ j Pÿt$ ÿV
> > fø ."
> > ?C
> > > ÿt$ VèiÅýÿf?D$ fÄ ÿt$ ff|$ ÿt$ W ÛVfCè Åýÿf<ÃfÄ ]_^[fÄ
> > Ãÿt$ ÿt$ WVèûÄýÿf¸ fÄ ëàÿt$ ÿt$ WVèãÄýÿf¸
> > fÄ ëÈU<ìfì<S?EÜV?MàW > ?EÈ<} PWÿuàVè÷æÿÿfÄ f.Àt ÿuÜÿuàÿu Vè"Äýÿf¸ fÄ é*
> > ÿuàÿV f > SMèÓè ·Êf@?MÔf?Eìj
> > ·G$ EÈ?EØ?DËøP?EðÿuàÿV ;Eðt ÿuÜÿuàÿu Vè Äýÿf¸
> > fÄ é- j ?EîPÿuàÿV fø t ÿuÜÿuàÿu VèØÃýÿf¸ fÄ é SMèj
> > ·UîÓâ ·Eæ?L Q?MÐÿuàÿV ;EÐt ÿuÜÿuàÿu Vè>Ãýÿf¸ fÄ éÄ
> > j ?EæPÿuàÿV fø t ÿuÜÿuàÿu VèoÃýÿf¸ fÄ é~ f > f > j@WÿuàÿV
> > fø@t ÿuÜÿuàÿu Vè Ãýÿf¸ fÄ é4 j
> > SÿuàÿV ;Ãt ÿuÜÿuàÿu VèãÂýÿf¸ fÄ é fÇEðÿÿfÇEþ ff}ô ">
> > j WÿuàÿV fø .¸ f< f?Eúf9Eîwgs f >
> >
> >
> > blah blah blah....

[Ben Myers]

I suggest a virus scan. Stinger will fit on a floppy.

http://download.nai.com/products/mcafee-avert/stinger.exe

Ben

"Rex" > wrote in message =
om...
> I've run scandisk on an old HP/Win98 machine. Comes up with no
> problems. I ran it because I suspected cross linked files. Here's
> why.
>=20
> I sell an application that runs a cool java database called hsql.=20
> Long story short a user called me one day and said the database
> wouldn't start. Lots of troubleshooting later I found the problem -
> junk appended to the end of the main datafile corrupting it. The junk
> appeared to be part of another file on her system, almost as if
> windows didn't know where my data file ended. Cut the junk out of the
> file and the database starts fine. Problem repeats though randomly
> over the course of the next week each time with different garbage from
> her system showing up.
>=20
> Positive it's not my program. There are hundreds of installations of
> it out there with the same exact build (including one on another
> identical HP machine in this customer's office) and never has this
> problem been seen. The user has also reported other random errors on
> this particular machine including office back-up utilities choking on
> it.
>=20
> Take a look at the end of the datafile in the last case of the error
> and tell me if you think this looks like crosslinked files.
>=20
> Here's what the divide at the end of the data file looked like (name
> and address in the record shown here modified to protect the
> innocent)...
>=20
> DELETE FROM CLIENT WHERE ID=3D288
> INSERT INTO CLIENT VALUES(288,'Smith,
> =
Angie',NULL,'Larro',NULL,'Angie',NULL,NULL,NULL,NU LL,NULL,NULL,NULL,'204
> N Tarpid =
Blvd',NULL,'Mayberry','NJ','08112-','',NULL,'','(',NULL,'','(',NULL,'','(=
',NULL,'',NULL,NULL,NULL,NULL,NULL,'House
> Account','11/10/2004',false,NULL,false)
> COMMIT
> SET AUTOCOMMIT TRUE
> SET AUTOCOMMIT FALSE
> COMMIT
> SET AUTOCOMMIT TRUE
> SET AUTOCOMMIT FALSE
> COMMIT
> SET AUTOCOMMIT TRUE
>=20
>=20
>=20
> .....All of that stuff is normal. We see it all the time....
>=20
> .....This stuff that follows though is not and goes on for hundreds of
> lines. The "NextPart_000" stuff makes me think it's part of some
> email message or something....
>=20
>=20
>=20
> ------=3D_NextPart_000_0005_01C4C728.05DFF880-- =
=20
> v=07=81m=F4 =10=20
> > =8D.=B8=FE=FF=FFP=FFu=FC=FFS =3D=F8 =
t=1B=FFu=F0=FFu=FC=FFu=10S=E8=B4=C8=FD=FFf=B8=01 f=C4=10=E9:=01 j
> W=FFu=FC=FFS=10;=C7t=1B=FFu=F0=FFu=FC=FFu=10S=E8O= C8=FD=FFf=B8=01 =
f=C4=10=E9=12=01=20
> j(=8DE=B0P=FFu=FC=FFS =
f=F8(t=1B=FFu=F0=FFu=FC=FFu=10S=E8`=C8=FD=FFf=B8=0 1 f=C4=10=E9=E6 > =
?E=F8f3=C0f}=F8 v=0Ef@=C6=02 =0F=B7=C8B;M=F8r=F2 > f=C4=10=E9f > =
=FFu=FC=FFu=10S=1B=F6=E8=A6=C7=FD=FFfFf=C4=10f<=C6=EB.=FFu=F0=FFu=FC=FFu=10=
S=E8=8D=C7=FD=FFf=B8=01 =
f=C4=10=EB=16=FFu=F0=FFu=FC=FFu=10S=E8u=C7=FD=FFf= B8=04
> f=C4=10_^[<=E5]=C3f=EC =
=C6D$=14=CD=C6D$=15f=C6D$=16<=C6D$=17=E5=C6D$=18=1F=C6D$=19]=C6D$=1AMSVWU=
=8DD$=1C=8DL$=14<|$<P > =C6D$5 WV=E8=D2=C6=FD=FFf=C4=10f.=C0t f=B8=01 =
=E9=F2=01 j h=BD[=01 =FFt$=1C=FFV=10=3D=BD[=01 =
t=1B=FFt$=1C=FFt$=18WV=E8=E0=C6=FD=FFf=B8=01
> f=C4=10=E9=C2=01 =
=8DD$=12j=02P=FFt$=1C=FFV=08f=F8=02t=1B=FFt$=1C=FF t$=18WV=E8=B2=C6=FD=FFf=
=B8=01 f=C4=10=E9"=01=20
> f=81|$=12ZMt$f=81|$=12MZt=1B=FFt$=1C=FFt$=18WV=E8. =C6=FD=FFf=B8=04 =
f=C4=10=E9g=01 j h=D9[=01 =FFt$=1C=FFV=10=3D=D9[=01
> t=1B=FFt$=1C=FFt$=18WV=E8U=C6=FD=FFf=B8=01 f=C4=10=E97=01 =
=8DD$=12j=02P=FFt$=1C=FFV=08f=F8=02t=1B=FFt$=1C=FF t$=18WV=E8'=C6=FD=FFf=B8=
=01
> f=C4=10=E9 =01 =FFt$=14=0F=B7D$=16=05=BD[=01 ?D$=1C=FFV=14?D$ =
f=F8=FFu=1B=FFt$=1C=FFt$=18WV=E8=EE=C5=FD=FFf=B8=0 1 f=C4=10=E9=D0 =20
> f=C7D$=12MM > =
PU=FFt$$=FFt$P=FFt$(V=E8=AC=C6=FD=FFf=C4=1C<=D8f=FB=FFt;j =
S=FFt$=1C=FFV=10;=C3=0F." =8DD$=12j=02P=FFt$=1C=FFV f=F8=02=0F." =20
> =8DC
> > =FFt$=18V=E8i=C5=FD=FFf?D$=1Ef=C4 =
=FFt$=1Cff|$=16=01=FFt$=18W=1B=DBVfC=E8=18=C5=FD=F Ff<=C3f=C4=10]_^[f=C4
> =C3=FFt$=1C=FFt$=18WV=E8=FB=C4=FD=FFf=B8=01 =
f=C4=10=EB=E0=FFt$=1C=FFt$=18WV=E8=E3=C4=FD=FFf=B8 =01
> f=C4=10=EB=C8U<=ECf=EC<S=8DE=DCV=8DM=E0W > =
=8DE=C8<}=14PW=FFu=E0V=E8=F7=E6=FF=FFf=C4=10f.=C0t=1B=FFu= DC=FFu=E0=FFu=10=
V=E8"=C4=FD=FFf=B8=04 f=C4=10=E9=AD=07=20
> =FFu=E0=FFV=14f > SM=E8=D3=E8=0F=B7=CAf@?M=D4f?E=ECj =
=0F=B7G$=03E=C8?E=D8=8DD=CB=F8P?E=F0=FFu=E0=FFV=10 ;E=F0t=1B=FFu=DC=FFu=E0=
=FFu=10V=E8=04=C4=FD=FFf=B8=01
> f=C4=10=E9-=07 =
j=02=8DE=EEP=FFu=E0=FFV=08f=F8=02t=1B=FFu=DC=FFu=E 0=FFu=10V=E8=D8=C3=FD=FF=
f=B8=01 f=C4=10=E9=01=07 SM=E8j
> =
=0F=B7U=EE=D3=E2=0F=B7E=E6=8DL=02=01Q?M=D0=FFu=E0= FFV=10;E=D0t=1B=FFu=DC=FF=
u=E0=FFu=10V=E8>=C3=FD=FFf=B8=01 f=C4=10=E9=C4=06=20
> =
j=02=8DE=E6P=FFu=E0=FFV=08f=F8=02t=1B=FFu=DC=FFu=E 0=FFu=10V=E8o=C3=FD=FFf=
=B8=01 f=C4=10=E9~=06 f > f > j@W=FFu=E0=FFV =
f=F8@t=1B=FFu=DC=FFu=E0=FFu=10V=E8 =C3=FD=FFf=B8=01 f=C4=10=E94=06 j
> S=FFu=E0=FFV=10;=C3t=1B=FFu=DC=FFu=E0=FFu=10V=E8=E 3=C2=FD=FFf=B8=01 =
f=C4=10=E9 =06 f=C7E=F0=FF=FFf=C7E=FE ff}=F4 =0F"> =20
> j=08W=FFu=E0=FFV=08f=F8=08=0F.=B8 f<=07f?E=FAf9E=EEwgs=1Ff >=20
>=20
>=20
> blah blah blah....

[Jeff Richards]

Check the hard disk cache settings. Make sure that write-behind caching is
turned off.

Does the application have a close file option? Is there a difference
between closing the window using the X button, and selecting a close option
within the application? Have you watched the operator closing the
application and the system, to see if there any shortcuts being taken. As
you say, there has to be a some difference between this machine and the
others, and I suspect it's in the operation, and specifically in the
file-closing process.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Rex" > wrote in message
om...
> If I read you correctly, there would be missing data. All data,
> however, is accounted for and is being saved to disk (verified the
> number of records using backed up versions of the file and knowlege of
> subsequent activity). Moreover, HSQL data files are simply lists of
> SQL commands (no binary data) so it makes it real easy to verify that
> you have what you think you should have.
>
> As I mention in my post, it really would be unlikely that it is
> something within the application. If it were, why would just this one
> machine among hundreds of installations exhibit the problem. In the
> office in question, next to the machine in question, is another
> machine just like it. Same software configuration on same model
> machine. No problems there.
>
> I believe the other symptoms experienced on this particular machine,
> which I mentioned in my post, point towards some sort of unique
> failure on this particular machine. Just can't put my finger on it.
> Hard drive scans produce no problems. Memory maybe?
>
> Not critical. They'll get new machines eventually. Just one more of
> those wierd mysteries though that I wish I had an answer to. I'd be
> the man if I could solve this one :)
>
>
> "Jeff Richards" > wrote in message
> >...
>> This is not necessarily crosslinked files. It could simply be that the
>> system is allocating space to the file, but whatever data is being
>> written
>> to the newly allocated space (if any) is not getting saved to disk. The
>> file is valid as far as the file system is concerned. The garbage is
>> whatever happened to be on disk in the newly allocated sectors. I would
>> look at a cache setting, as it seems that your application thinks the
>> file
>> contains more data than it really does. Can you confirm if any data is
>> missing from the file after it becomes corrupted like this (data that
>> should
>> have been written to disk in the new sectors)? I would also look at the
>> process by which the file is being closed, as the application may require
>> a
>> close command to truncate the file at the actual end of data (instead of
>> end
>> of physical file).
>> --
>> Jeff Richards
>> MS MVP (Windows - Shell/User)
>> "Rex" > wrote in message
>> om...
>> > I've run scandisk on an old HP/Win98 machine. Comes up with no
>> > problems. I ran it because I suspected cross linked files. Here's
>> > why.
>> >
>> > I sell an application that runs a cool java database called hsql.
>> > Long story short a user called me one day and said the database
>> > wouldn't start. Lots of troubleshooting later I found the problem -
>> > junk appended to the end of the main datafile corrupting it. The junk
>> > appeared to be part of another file on her system, almost as if
>> > windows didn't know where my data file ended. Cut the junk out of the
>> > file and the database starts fine. Problem repeats though randomly
>> > over the course of the next week each time with different garbage from
>> > her system showing up.
>> >
>> > Positive it's not my program. There are hundreds of installations of
>> > it out there with the same exact build (including one on another
>> > identical HP machine in this customer's office) and never has this
>> > problem been seen. The user has also reported other random errors on
>> > this particular machine including office back-up utilities choking on
>> > it.
>> >
>> > Take a look at the end of the datafile in the last case of the error
>> > and tell me if you think this looks like crosslinked files.
>> >
>> > Here's what the divide at the end of the data file looked like (name
>> > and address in the record shown here modified to protect the
>> > innocent)...
>> >
>> > DELETE FROM CLIENT WHERE ID=288
>> > INSERT INTO CLIENT VALUES(288,'Smith,
>> > Angie',NULL,'Larro',NULL,'Angie',NULL,NULL,NULL,NU LL,NULL,NULL,NULL,'204
>> > N Tarpid
>> > Blvd',NULL,'Mayberry','NJ','08112-','',NULL,'','(',NULL,'','(',NULL,'','(',NULL,'',N ULL,NULL,NULL,NULL,NULL,'House
>> > Account','11/10/2004',false,NULL,false)
>> > COMMIT
>> > SET AUTOCOMMIT TRUE
>> > SET AUTOCOMMIT FALSE
>> > COMMIT
>> > SET AUTOCOMMIT TRUE
>> > SET AUTOCOMMIT FALSE
>> > COMMIT
>> > SET AUTOCOMMIT TRUE
>> >
>> >
>> >
>> > .....All of that stuff is normal. We see it all the time....
>> >
>> > .....This stuff that follows though is not and goes on for hundreds of
>> > lines. The "NextPart_000" stuff makes me think it's part of some
>> > email message or something....
>> >
>> >
>> >
>> > ------=_NextPart_000_0005_01C4C728.05DFF880--
>> > v ?mô
>> > > ?.¸þÿÿPÿuüÿS =ø t ÿuðÿuüÿu Sè´Èýÿf¸ fÄ é: j
>> > WÿuüÿS ;Çt ÿuðÿuüÿu SèOÈýÿf¸ fÄ é
>> > j(?E°PÿuüÿS fø(t ÿuðÿuüÿu Sè`Èýÿf¸ fÄ éæ > ?Eøf3Àf}ø v f@Æ
>> > ·ÈB;Mørò >
>> > fÄ éf > ÿuüÿu S öè¦ÇýÿfFfÄ f<Æë.ÿuðÿuüÿu Sè?Çýÿf¸
>> > fÄ ë ÿuðÿuüÿu SèuÇýÿf¸
>> > fÄ _^[<å]Ãfì ÆD$ ÍÆD$ fÆD$ <ÆD$ åÆD$ ÆD$ ]ÆD$ MSVWU?D$ ?L$ <|$<P >
>> > ÆD$5
>> > WVèÒÆýÿfÄ f.Àt f¸ éò j h½[ ÿt$ ÿV =½[ t ÿt$ ÿt$ WVèàÆýÿf¸
>> > fÄ é ?D$ j Pÿt$ ÿV fø t ÿt$ ÿt$ WVè²Æýÿf¸ fÄ é"
>> > f?|$ ZMt$f?|$ MZt ÿt$ ÿt$ WVè.Æýÿf¸ fÄ ég j hÙ[ ÿt$ ÿV =Ù[
>> > t ÿt$ ÿt$ WVèUÆýÿf¸ fÄ é7 ?D$ j Pÿt$ ÿV fø t ÿt$ ÿt$ WVè'Æýÿf¸
>> > fÄ é ÿt$ ·D$ ½[ ?D$ ÿV ?D$ føÿu ÿt$ ÿt$ WVèîÅýÿf¸ fÄ éÐ
>> > fÇD$ MM > PUÿt$$ÿt$Pÿt$(Vè¬ÆýÿfÄ <Øfûÿt;j Sÿt$ ÿV ;à ." ?D$ j Pÿt$ ÿV
>> > fø ."
>> > ?C
>> > > ÿt$ VèiÅýÿf?D$ fÄ ÿt$ ff|$ ÿt$ W ÛVfCè Åýÿf<ÃfÄ ]_^[fÄ
>> > Ãÿt$ ÿt$ WVèûÄýÿf¸ fÄ ëàÿt$ ÿt$ WVèãÄýÿf¸
>> > fÄ ëÈU<ìfì<S?EÜV?MàW > ?EÈ<} PWÿuàVè÷æÿÿfÄ f.Àt ÿuÜÿuàÿu Vè"Äýÿf¸ fÄ
>> > é*
>> > ÿuàÿV f > SMèÓè ·Êf@?MÔf?Eìj
>> > ·G$ EÈ?EØ?DËøP?EðÿuàÿV ;Eðt ÿuÜÿuàÿu Vè Äýÿf¸
>> > fÄ é- j ?EîPÿuàÿV fø t ÿuÜÿuàÿu VèØÃýÿf¸ fÄ é SMèj
>> > ·UîÓâ ·Eæ?L Q?MÐÿuàÿV ;EÐt ÿuÜÿuàÿu Vè>Ãýÿf¸ fÄ éÄ
>> > j ?EæPÿuàÿV fø t ÿuÜÿuàÿu VèoÃýÿf¸ fÄ é~ f > f > j@WÿuàÿV
>> > fø@t ÿuÜÿuàÿu Vè Ãýÿf¸ fÄ é4 j
>> > SÿuàÿV ;Ãt ÿuÜÿuàÿu VèãÂýÿf¸ fÄ é fÇEðÿÿfÇEþ ff}ô ">
>> > j WÿuàÿV fø .¸ f< f?Eúf9Eîwgs f >
>> >
>> >
>> > blah blah blah....