Saturday, March 27, 2010

Carbonite and PRG files: Problem and Workaround

I've been using Carbonite for online backup for a few years now. I did try XDrive and I have earlier posts about how horrible it was.

One thing I've always liked about it is the ability to pull back individual files almost like an incremental version update. The fact that the backup drives integrate perfectly with Windows Explorer is a definite plus.

But when my laptop bit the dust recently (a <12 month old Toshiba power jack issue), I was hoping to rely on it for the restoring my files onto my new laptop. While I did have the physical drive from the Toshiba, I wanted to test it out for a full restore.

That's when I found a major problem. By default, Carbonite does not backup what it considers to be system files (EXE, DLL, COM, etc). It does backup VB, CS , ASPX files without a problem. But Carbonite considers a PRG file to be a system file. I'm not quite sure why - but it does. As a result, none of my PRG files were backed up.

As a FoxPro developer, this is tantamount to disaster. I would restore all my files and while the VFP screens and class libraries were all present - I couldn't run any of my code because it was missing a PRG file.

I contacted Carbonite about this and the first response was "sorry, we don't back up system files". What is interesting is that this post lists off the files that Carbonite considers system files.

That list is at the end of this post.

But there is a workaround.

If you highlight a PRG file and right-click, you can choose Properties. Click on the Carbonite tab and check the option to Backup Files of this type.



This solves the problem. So now, all of your PRG files will be backed up.

But what system file ends in PRG?

For reference, here is a list of all the file extensions that Carbonite will not backup in alphabetical order:

.$$$
.$db
.113
.BSC
.IDB
.ILK
.NCB
.OBJ
.PCH
.PDB
.SBR
.abf
.abk
.afm
.ani
.ann
.bac
.bak
.bck
.bcm
.bdb
.bdf
.bkf
.bkp
.bmk
.cab
.cf1
.chm
.chq
.chw
.cnt
.com
.cpl
.cpl
.cur
.dev
.dfont
.dll
.dmp
.drv
.drv
.dvd
.eot
.evt
.exe
.ffa
.ffl
.ffo
.ffx
.fnt
.fon
.ftg
.fts
.fxp
.gid
.grp
.hlp
.hxi
.hxq
.hxr
.hxs
.ico
.idx
.img
.inf
.ini
.ins
.ipf
.iso
.isp
.its
.jar
.jse
.kbd
.kext
.key
.lex
.lib
.lnk
.log
.lwfn
.msc
.msi
.msm
.msp
.mst
.nt
.obs
.ocx
.old
.ost
.otf
.otf
.pf
.pfa
.pfb
.pfm
.plist
.pnf
.pol
.pref
.prf
.prg
.prn
.pwl
.rdb
.reg
.reg
.rll
.rox
.scf
.scr
.sdb
.shb
.suit
.swf
.swp
.sys
.sys
.theme
.tmp
.tms
.ttc
.ttf
.ttf
.v2i
.vbe
.vga
.vgd
.vhd
.vmc
.vmdk
.vmsd
.vmsn
.vmx
.vxd
.vxd
.win
.wpk


Wednesday, March 03, 2010

And Then There Are The Pickles...

A little bit of fall-out from eTecnologia's apparent abandonment of the VFP.Net project.

VFPX could suffer from the same fate except that those involved are already supporting it as an open-source project.

There are lots of ways of working with VFP in .Net and in any language. I use VFP pretty much every day and it's not part of the client's arsenal - but it turns around the work I need done - be it prototypes, sample data input and more...it's faster and better than the alternatives. But it is simply one tool in the toolbox - like the screwdriver that seems to fix almost every problem - there are always times to use others.

I'll post a little more on my own experiences but Hank's post here is very telling. We've heard about VFP Studio and also now about VFP.Net - in both of these cases, it might have been better to open source the two.

ProSysPlus Blog: And Then There Are The Pickles