dbf files in \program files (x86)\ directory on Windows 7 64-bit

[grahamrhind]

Possibly a weird issue that I'd like to understand ...

I discovered that the contents of my dbf files (created by Visual Foxpro 9) were becoming "corrupted" when installed in the \program files (x86)\ directory of a Windows 7 64-bit system, whilst installing them anywhere else on the disk, or on an XP or Vista machine does not cause this issue.

See a before (top 3 records)/after (bottom 3 records) example here:

http://dl.dropbox.com/u/450542/BeforeAfter.png

I know that this is not a VFP or InstallShield issue as copying the good files just using Windows Explorer into that directory causes exactly the same corruption. I don't know enough about Windows 7 64-bit to be able to work out what is going on. Has anybody else experienced this, or can anybody shed any light on why this is happening?

Thanks in advance!

 

[linney]

I can't offer an explanation other than perhaps the physical area of your hard drive that the Program Files inhabit has itself become damaged?

Try running ChkDsk to check your drive for errors. Right-click your Drive icon/ Properties/ Tools/ Error Checking. Try it first by not checking either box (Read-only mode) to see if it flags any hard drive or file problems. If it does, start by ticking both boxes, in any further rerun.

The hard drive manufacturer will have free diagnostic software that is bootable, or that may even run from within Windows, that will thoroughly check the condition of your hard drive.

Do you use any file encryption software?

 

[grahamrhind]

Thanks Linney. The drive is checked for errors every week, and a chkdsk shows no problems. This issue has been around for many months, so I think it's an OS issue that I can't fathom. The dbf files are "encrypted" but only by substituting one ASCII character with another, so the files' fields contain plain text. Checking the properties of the \program files (x86)\ directory the only thing that looks a possible suspect is that the files are allowed to be indexed for searching, but I don't see how that might be allowed to affect the files' contents.

 

[dilettante]

Data does not belong under the Programs diretory(ies). My guess is that you're running a mix of elevated and non-elevated processes and probably even with UAC disabled on the Vista system (for shame!). No manifests either hmm?

Probably a simple case of filesystem virtualization confusion.

 

[micker377]

Is your problem program certified to operate properly under Win 7? Is an upgrade from Foxpro necessary?

 

[grahamrhind]

@dilettante: thanks, though I only understood about 3 words in your message. If data (as lookup tables) is being shipped with an exe program, I would have though that that directory was the place it should go. Installing the whole program outside the \program files (x86)\ directory doesn't give the issues, and is the workaround I'm now using, but I would like to understand why this specific directory causes the problem. Everything you wrote after "My guess" might as well have been written in Mongolian for all it meant to me The setup files are being created using InstallShield with full rights. That's as much as I know or understand.

@micker377: Foxpro is no longer being updated, but it does run on Windows 7 64-bit and it does run without issue when installed anywhere else in the folder structure.

Graham

 

[BadBigBen]

since the files are actually plain TEXT files, then I would suggest the following, rename the DBF files (or just one) as a test to TXT, and then copy into the PROGRAM FILES (x86) folder...

see if they are corrupted...

then rename them back to DBF...

see if they are then corrupted...

if the files are not corrupted when copying them as TXT files, then perhaps DBF extension handling could be corrupted, see which programs installed handle DBF other than FoxPro...

more questions:

how large are these files and what is the FS in use?

are they shared over the network?


see:

Potential file corruption when using Windows Vista/Windows 7 or Windows Server 2008/Windows Server 2008 R2 with SMB2

http://www.caseware.com/support/caseknowledge/kb-271

and

How to Disable SMB 2.0 on Windows Vista/2008

http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

Just some thoughts...



Ben
"If it works don't fix it! If it doesn't use a sledgehammer..."
How to ask a question, when posting them to a professional forum.
Only ask questions with yes/no answers if you want "yes" or "no"

 

[grahamrhind]

@BigBadBen

Some good thinking there! Thanks!

Renaming dbf->txt and copying the txt does NOT result in the corruption.
Renaming that txt->dbf in the destination directory also does NOT result in the corruption. So something is affecting files only with the .dbf extension.

Foxpro is the only program now on the PC that works with .dbf files, as far as I can see. The files are not being copied over a network, so I presume that the SMB issue you highlighted isn't the issue. The file sizes vary but are always under 2 GB (the maximum allowed for Foxpro). File system: NTFS.

I should emphasize something I hadn't mentioned: copying bog standard dbf files does not cause the issue. The issue manifests itself when I use a simple "cloaking" device to stop people easily reading what's in the files. This simply replaces one letter with another. A with Z, B with Y etc. So the contents are still normal ASCII. But it is ONLY those fields which have the problem.

Also, remember, a simple copy using Windows Explorer also results in the problem, so I am loathed to think it's a problem with Foxpro. Though I am running out of ideas ....

Graham

 

[BadBigBen]

The issue manifests itself when I use a simple "cloaking" device

since I am not familiar with FoxPro, simple question, does it install a driver or service for the "cloaking"? if so, then that is the problem or that is where the issue is most likely to be found...

but seeing that it works outside of the PROGRAMME FILES (x86) folder, I would live with that workaround... stumped...


Ben
"If it works don't fix it! If it doesn't use a sledgehammer..."
How to ask a question, when posting them to a professional forum.
Only ask questions with yes/no answers if you want "yes" or "no"

 

[grahamrhind]

Thanks Ben. No driver or service is installed for that cloaking - it just translates one character with another and writes it back to the field.

Stumped indeed!