Shirt Pocket Discussions - SD and lost disk space

Shirt Pocket Discussions (https://www.shirt-pocket.com/forums/index.php)

- General (https://www.shirt-pocket.com/forums/forumdisplay.php?f=6)

- - SD and lost disk space (https://www.shirt-pocket.com/forums/showthread.php?t=2259)

SD and lost disk space

At http://forums.bombich.com/viewtopic.php?t=3852 Andreas, the Bombich forum moderator, points to a situation where the absence of the target drive when a back up is scheduled, or where a backup is interupted part way through, when using CarbonCopyCloner can result in loss of space on the source drive:

Quote:

If a scheduled task ran when the target volume was not available, or if the target became unavailable during a cloning, you will need to remove items that will have been copied to your startup disk.

He later goes on to say:

Quote:

Do something to ensure that whenever a schedule runs the target will be available so that you don't have to do this too often!

NB CCC does not cause the creation of a 'false clone'; it is the way the Operating System functions when the designated target for a copying procedure cannot be found.

I have never tried interupting an ongoing back-up using SD but I certainly haven't experienced this issue simply because my target volume wasn't available. Instead I simply get a polite message telling me that the drive can't be found and the process stops.

Is an interrupted backup with SD likely to result in loss of space on the source disc space? I've seen quite a few mentions of this as an issue with CCC on the Apple Discussions boards, but not with respect to SD. If it is really an "OS" issue, as the Bombich site suggests, wouldn't the problem be inevitable? Or does SD do such things differently somehow?

Cheers

Rod

Missing volumes would absolutely not cause this kind of problem with SD. However, there are situations where, if the drive we're copying to fails in a way that doesn't notify us, files can, indeed, be copied to the source.

This is because "external drives" are address through a "mount point", which looks just like a folder. In some situations, this folder can convert to a "real" folder, which we continue copying to.

We could check, before every operation, whether the folder was a real folder or a fake one. Doing so, however, would mean an especially slow additional operation would occur for every single file copied. Rather than do this, we check before any destructive operation. This ensures we don't do anything "bad".

As you've likely seen elsewhere in the forum, the "fix" -- should this happen -- is simple: use Finder's "Go To Folder" command to open the hidden "/Volumes" folder, then remove any folders in there (any "real" items would be links).

Hope that helps to explain how/why things might fail. It's not a terribly frequent occurrence...

Many thanks for the fast and informative response, David!

Cheers

Rod