The support forum

More exception rules

genl :

Oct 16, 2013

An addition to my previous post in beta 41 thread.

I have added .\$RECYCLE.BIN folder into exception list. After the job is done, I found the Bvckup archived this folder on destination (at "$Archive of Deleted Items (Bvckup)"). It did so every single time it seems. My job is set to "archive backup copies of deleted items".

Expected behavior: if I specifically exclude .\$RECYCLE.BIN or .\RECYCLER, there is no point to delete or archive the recycle bin on destination. Because Windows will re-create it later anyway.

Again, speaking about a case where both source and destination are hdd root folders...

Will it be possible to exclude anything from processing on destination at some point? It seems I may want to skip not only Recycle bin but some other folders too - I'd need them to stay on the backup device (for other needs) so they can be used/filled by other apps.

I understand it's possible to simply create several backup jobs for each folder in the hdd root, thus skipping the folders I don't need, but that would mean >10 jobs instead of one.
Also, a simplier solution would be to create a separate folder for destination. This, however, would mean that if my source hdd contains any too-long pathnames, they may not be replicated correctly.

This suggestion would also mean that the source and the destination won't be 100% same anymore, but still - can it be useful enough to be implemented in future?

Alex Pankratov :

Oct 17, 2013

Will it be possible to exclude anything from processing on destination at some point?

It already supports this, but it is presently used only to exclude System Volume Information folder when copying to the root of the drive. I can easily add $Recycle.bin and Recycler to that list.

This will be in the B42. Thanks for the nudge.

genl :

Oct 17, 2013

But what about user-defined folders, like in the the described case? Switching to "Keep backup folders" will be the only way?

Alex Pankratov :

Oct 18, 2013

I would rather not add support for this, but this ties directly into the other idea of treating destination directory as a shared resource (rather than as an exclusive one as the app assumes now) -

This is fairly advanced use-case. I can absolutely see this being useful, but I also think that it doesn't belong to the standard revision of the app.

genl :

Oct 18, 2013

Thanks for explanation.
That's it for me then, I can try either of 3 workarounds I mentioned here, depending on severity of their drawbacks in my personal case.

Just in case you change the plans about this in future - count me in as +1 interested person.

New topic

Made by IO Bureau in Switzerland

Blog / RSS
Follow Twitter
Miscellanea Press kit
Company Imprint

Legal Terms