SyncToy 2.0B large files can run out of diskspace

  • Thread starter Thread starter bb_aes
  • Start date Start date
B

bb_aes

I am using SyncToy 2.0 Beta on an XP machine with NTFS file systems. There
is one very large (1GB) file in my folder pair and if this was changed on the
source, SyncToy cannot copy it to the destination. The reason is that it
runs out of disk space. However, the file that was changed is the exact same
size, so it already exists on the destination. There is 800MB free on
destination and the file is 1GB in size. Might it be that it is trying to
make a full 1GB copy of the file before deleting the file being copied over?
Can't the file be deleted (or moved to recycle bin) before the copy takes
place? Even if the file would not fit in the recycle bin, it should not
error out by running out of disk space. There should be 800 MB free before
and 800 MB free after the operation. I can copy the file by hand, but isn't
that SyncToy's job? It seems like others would have this same problem when
using memory sticks, but I did not find reference to it in other posts.
Thank you for clearing this up for me.
 
bb_aes said:
Might it be that it is trying to make a full 1GB copy of the file
before deleting the file being copied over?
Click to expand...

Most backup systems create a temporary file before erasing your previous
backup, just in case something goes wrong creating the new backup. There
is no option to erase the previous backup before proceeding, and it
would be rather dangerous if it did exist.
Moving the previous file to the Recycle would not help - the file still
takes up the same amount of disk space.

The one option that exists (especially in the case of memory sticks) is
to buy one twice the size. :-) Then everything fits, for a while.
 
Thank you for your input. I don't agree that it is "dangerous" to delete the
previous destination file before copying to it, as you are overwriting the
file anyway. Also, you still have the source intact. It should at least be
an option we can turn off for selected folders or files. As for it being in
the Recycle Bin, this should have no effect on the copy, since the recycle
bin has a fixed size. In my case the file would be too large to fit in the
recycle bin, so would be just deleted.

Does anyone know if there is a fix planned for this problem with synctoy?
Having to buy disk drives or memory sticks twice the size we need just to
work around this problem does not seem to be a viable solution. A better
workaround is just to copy these large files manually before running synctoy.
Then when it runs it will see them as the same. However manually copying
the files defeats the whole synctoy usefulness.
Thanks.
 
bb_aes said:
Thank you for your input. I don't agree that it is "dangerous" to delete the
previous destination file before copying to it, as you are overwriting the
file anyway.
Click to expand...

Ok, so you start your backup. The new backup won't fit, so it erases
your previous backup. Halfway through your new backup your input drive
fails. Where are you going to restore from? If you already had two
backups you'd be better off deleting the older and still using the
standard mechanism.

With the backup to new file, then erase old, then rename new to old
mechanism, there is no time when you don't have a complete backup.
 
Thanks for your thoughts. Perhaps this safeguard is required if you are
using SyncToy as your only backup method and you only have one copy of the
backup and your source file just happens to fail when copied. However, if
this is to be a synchronize tool it should have capabilities to sync up two
systems without requiring double the needed size of storage on both sides.
Perhaps the method you mention is okay for the default method, but there
should certainly be an option on either folder pairs or individual files if
we want to have it make a duplicate copy first. The old MS Briefcase which
SyncToy is supposed to be a replacement for did not have this drawback. It
could replace a large file on the destination without requiring tons of blank
disk space just do do so. And as far as worries about the source file not
being valid, if a copy to the destination fails it is not due to the source
file being bad as much as it is the network it is going over being bad, or
not enough space on destination, etc. I do hope MS puts this fix to have the
option in SyncToy in future releases. It is a big drawback from Briefcase
and I can see being a bigger problem when using smaller memory sticks or
cards for a transfer medium. Finally, as per losing your whole backup (if
this is your only method), that is not true either. You are only losing this
one file, and all you are losing is the one old copy of the one file.
Bill
 
Back
Top