A common problem with data migration at the file level is that you can end up with users complaining of zero-length files. The problems come when you re-run the copy in the hope that the zero-byte files in the destination folder structure are updated with healthy ones from the source. Since the zero-byte files will have a newer time stamp than the source data, they become impossible to “fix” without potentially affecting surrounding files.
The best solution I’ve found is to identify and delete any files that are zero-bytes in length before re-running another copy.
To recursively delete zero-byte files in your folder structure, use the following command
for /r %F in (*) do if %~zF==0 del “%F”
If you wish to include the command in a batch file, you’ll need to double up on the % characters,
for /r %%F in (*) do if %%~zF==0 del “%%F”
This will remove the zero-byte files, allowing you to subsequently re-copy the now missing files from the source
robocopy.exe “%source%” “%dest%” *.* /S /XO /FFT /MT:10
Note: to set your source and destination paths in a batch file, use the following syntax
SET “source=R:\MOVED\Mydata”
SET “dest=T:\Mydata”
To simply find zero-byte files and append their full pathnames to a logfile, use
for /r %F in (*) do if %~zF==0 echo “%F” > e:\logs\zerobytefiles.log
I tried this and it did not find a 0 byte file in my downloads folder.
Is their any way I can get rid of this 0 byte file??
if you have a zero byte file that won’t delete, you may find that file vanishes after unmounting and re-mounting the filesystem (or rebooting the entire OS). Failing that, I’d be concerned that the file system was corrupt and would consider recovering all files from backup onto a freshly formatted drive. This is assuming that the user youre using to delete the file does actually have read, write, execute and delete access to the file of course!