It's a matter of terminology really. To each his own. For example, I disagree that compression is an expected part of backup. Nor do I think that Restore should be a built-in app's function, especially if it"s essentially a thinly veiled basic file copy. I hear you that many people were led to believe that a backup without compression is not a "proper" backup, but that's not a reason enough for me to play along. This tendency to compete on the length of a feature list is very unfortunate.

So for example if the program can "hot feed" into an already zipped folder, then it ends up compressed and that's fine by me.

Restore might be a little more tricky.

Quote from: Jibz on October 22, 2013, 05:27 PM

I seem to remember we've discussed the name before -- I think "backup" gives people some associations about features like restore, compression, etc. As I understand it, what Bvckup does is one-way sync, which can be used for simple backups.

It's a matter of terminology really. To each his own. For example, I disagree that compression is an expected part of backup. Nor do I think that Restore should be a built-in app's function, especially if it"s essentially a thinly veiled basic file copy. I hear you that many people were led to believe that a backup without compression is not a "proper" backup, but that's not a reason enough for me to play along. This tendency to compete on the length of a feature list is very unfortunate.

Quote from: apankrat on October 22, 2013, 04:50 PM

You misunderstand what the delta copying is and I guess the explanation I have in the Backup Config window should be reworded -
(see attachment in previous post)
Delta copying doesn't copy deltas and store them in a separate file. It copies them into the existing backup copy. Think of it as a selective, per-block update of the backup copy. Performance-wise it makes no difference on the first run, but on the second run in vast majority of cases it delivers significant speed up (over copying file in its entirety).

I'm not so sure that I am. Copy Files In Full creates "snapshots" in a point in time, right?

Quote from: apankrat on October 22, 2013, 06:03 PM

It's a matter of terminology really. To each his own. For example, I disagree that compression is an expected part of backup. Nor do I think that Restore should be a built-in app's function, especially if it"s essentially a thinly veiled basic file copy. I hear you that many people were led to believe that a backup without compression is not a "proper" backup, but that's not a reason enough for me to play along. This tendency to compete on the length of a feature list is very unfortunate.

I think this is a trickier topic than it sounds. It chains a bit to your earlier remark about my theme.
"Submit a bug report for an unreleased theme to Microsoft - do I expect them to do anything? No."

But for these smaller apps, having the dev put in features feels to me like an important process, because it can change a user's opinion of the developer.

I firmly believe that versioning needs to be done in a way that doesn't lock file history to specific software. This means that the version archive format needs to be open and documented. This in turn means that I should either invent and document such format (but then someone else will need to code alternative tools to work with it) -or- I can adopt an existing format.

Can you guess where this is going? ... 3,2,1 ... That's right - it should use Git :-)

So the plan as it stands is to get the V2 on the road first and then to tackle file versioning.

Say you have C:\Temp\file.ext and you set it to be backed up to X:\Backup.
You run the backup first time, it creates X:\Backup\file.ext. An exact copy.

Then you go and edit C:\Temp\file.ext, change something in it.
You run the backup second time. It updates X:\Backup\file.ext and again it becomes an exact copy of C:\Temp\file.ext.

This happens regardless of whether you are using the full or the delta copier. The "full/delta" differences affects *how* the file is updated, but the net effect is the same - the backup copy becomes an exact replica of the original. Think of it as a performance optimization that allows the backup complete faster, but doesn't affect what's actually being done to the backup.

Does this make sense?

Quote from: apankrat on October 22, 2013, 07:17 PM

Quote from: TaoPhoenix on October 22, 2013, 06:19 PM

Quote from: apankrat on October 22, 2013, 04:50 PM

You misunderstand what the delta copying is and I guess the explanation I have in the Backup Config window should be reworded -
(see attachment in previous post)
Delta copying doesn't copy deltas and store them in a separate file. It copies them into the existing backup copy. Think of it as a selective, per-block update of the backup copy. Performance-wise it makes no difference on the first run, but on the second run in vast majority of cases it delivers significant speed up (over copying file in its entirety).

I'm not so sure that I am. Copy Files In Full creates "snapshots" in a point in time, right?

Correct, but so does the delta copying.

Just to be 100% clear: both create a snapshot, which gets modified as your files gets modified. It doesnt create a new snapshot at each backup. [Just in case the "snapshot[u]s[/u]" query was also about some form of versioning.]

Somehow it just makes me feel that all of that disappears with Deltas unless you have "perfect rollback to any point in time to recreate that day's files. Can your deltas do that?

...
One solution to get multiple snapshots would be to do like in the screenshots, and create a daily job that syncs to a folder called daily, and a weekly that syncs to a folder called weekly. That way, even if you screw up the daily snapshot, you have a weekly to fall back to.