unzap

[Olaf Doschke]

Since ZAP simply truncates a file like FCHSIZE() does to HEADER() size only + EOF byte, you could recover data doing the opposite FCHSIZE.

This is also what I found at

https://support.microsoft.com/kb/135905/EN-US

I tried the code and like it doesn't work for me. Partly it can't, because it's not at all addressing the FPT file, just the DBF part. I think it's not due to this MSDN article applying to older Foxpro versions only, but due to the NTFS filesystem and how FCHSIZE gets new sectors allocated by the filesystem.

The result with VFP9 and adding records by changing file size is documented in the help on FCHSIZE as:

When a file's size is increased, Microsoft Visual FoxPro allocates sectors for the file on the drive where the file is opened. Since FCHSIZE( ) does not initialize the new file space, the space can contain previous data. Be sure to manage the new file space.

In my case the result was empty records with no data, all zero bytes.

Does anyone have an old FAT partition available to check that it works in that file system, maybe an old USB thumb drive with just a few MB? It would be nice to see the dependency on the file system or if the FCHSIZE implementation really changed and made UNZIP impossible. In the end allocating random sectors of hdd space might have any unwanted side effects otherwise.

Bye, Olaf.

 

[Mike Lewis]

Olaf,

I have a FAT32 drive somewhere. I'll dig it out, and try the code.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

FYI, there's no rush, I do my backups.

Yet, it would be nice to know, even though this still will not make it practical, as Windows systems today don't have any considerable alternatives to NTFS anyway.
I might try it on a NAS drive.

Bye, Olaf.

 

[Mike Lewis]

I've just tried it on a FAT32 drive. This was with a free table with no CDX or memo file. The file had 55 records before I zapped it.

The result was that the 55 records were restored, but every field in every record is now filled with binary zeroes. The header looks correct, as far as I can see.

I'm not completely surprised. I would expect the header to be correct, as the program explicitly re-instates the record count. And I would expect the overall file length to be correct, because that's what FCHSIZE() does. So it looks like it is grabbing the correct amount of space, but not necessarily from the contiguous sectors (even though I was careful not to write anything else to the drive between the zap and the un-zap).

I might dig around a bit more later.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[DSummZZZ]

I personally think it's a waste of time to even bother with something like this. That article was written what, 20 years ago? The "Applies To" only includes up to VFP 3.0. Back when FAT drives were still prevalent. And when memory swapping to disk was happening continuously as it is now. It would be real easy for a virtual memory to overwrite blocks in short order on a local drive. And a server volume is constantly getting written to.
So yeah, as an experiment at the house, have fun. It will be useless in a production environment.


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Olaf Doschke]

Dave, you hit the nail right on the head. I already indicated I think it won't work on todays systems.

Nevertheless I still assume on some FAT system it could still work. I'd say the "applies to" section just doesn't mention further versions, as the article was never updated. But if it worked with old VFP versions only there also was a change in FCHSIZE, indeed a reassuring change as it won't simply fetch the next N free sectors not to think of sectors belonging to another file. Steady writing is unlikely the reason, if you write a test program doing ZAP and UNZAP right afterwards, swapping is done to one file on one drive mainly and not on any partition.

But it also doesn't work on a NAS, no matter what file system is working there under the hood.

Anyway, the idea was just popping and I was astonished this was really applicable at least in the past.

Bye, Olaf.

 

[vgulielmus]

I made this small test on a NTFS drive:

aaa=FCREATE('aa.txt')
?FPUTS(aaa,'mama')
?FCHSIZE(aaa,0)
?FCHSIZE(aaa,8) && one after another
FCLOSE(aaa)

The sane result : eight chr(0)

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[vgulielmus]

The second attempt was

aaa=FCREATE('aa.txt')
?FPUTS(aaa,'mama')
?FCHSIZE(aaa,0)
?FCHSIZE(aaa,4096) && the cluster size
FCLOSE(aaa)

Still nothing but zeroes CHR(0)

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[vgulielmus]

The third attempt :

aaa=FCREATE('aa.txt')
?FPUTS(aaa,'mama')
?FCHSIZE(aaa,3)
?FCHSIZE(aaa,6)
FCLOSE(aaa)

The result is : mam plus three of CHR(0)

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Mike Lewis]

I agree with Dave that it has little practical use. But it's still worth exploring, if only out of curiosity.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[vgulielmus]

The same results on a Fat32 USB (SO Win 7) with this code :

aaa=FCREATE('f:\aa.txt')
?FPUTS(aaa,'mama')
?FFLUSH(aaa,.T.)
?FCHSIZE(aaa,3)
?FFLUSH(aaa,.T.)
?FCHSIZE(aaa,6)
?FFLUSH(aaa,.T.)
FCLOSE(aaa)

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania