Big Backup File

I am using ATI workstation 9.1 to do a disk image to an USB harddrive which the backup file around 20 gb. I have hard time moving the file to other drive, I have tried so far around 4 computers and none of them able to copy from USB drive to another drive. Do you require a special program to move the extension "TIB" file. I use the copy and paste and is doesn't work. I even use the "CMD" and copy mode. May be the size is too big to move.

I like to know how is everybody use to move their backup files. I hate to keep on file on USB Portable drive because of accident drop and kill the drive.

thanks

rocky

 

do fixed size, 4.7 g, so it would fit on a DVD (multiple), easier to transfer smaller file;
I use external usb's, and am able to easily copy files

 

Are the drives USB 2?
The copy might be delayed by your AV software scanning.
Disable te AV just before the copy (make sure you are not connected to the internet when you do this), and enable the AV after the copy.

 

THehe USB portable drive is a Seagate 100 gb laptop drive which I put in a USB2 case. I will follow your direction disable Antivirius to see what happen. Also I didn't see you can make multiple file selection when I do a backup. May be I miss that. I have been use Ghost for many years but their create boot drive is suck especially on the USB drive.

So ATI is new to me.

thanks

rocky

 

I would not break up the file, unless you intend to copy the critters to DVD.

 

I think it may be because your USB drive is formatted as Fat 32 which has a file size limit of around 4Gb.

 

I disable the antivirius and it doesn't help and the drive is format as NTSF.

This is the error message"

"Cannot Copy backupfile: The path is too deep"

thanks

rocky

 

If that were the problem, there would be an error message.

 

What are you doing to copy?
Windows Explorer has no idea tat file being copied is a "backupfile".

Just open Windows EXplorer and Copy/Cut and Paste the file.

For example, I just told Windows Explorer to Copy a 28GB file from one USB drive to another.
It gave me a time estimate of about 44 minutes.

 

Ooops, I fergot to mention that since I am currently connected to te internet, I did not pause the AV.

If I ddisconnect from the internet, I would expect the copy to go a lot faster.

 

It is possible to have a path that is too deep, probably over 256 characters or so. However, this message seems to be one that is used as a catch-all when something unplanned goes wrong in a transfer.

I had it once copying 4 files from a notebook via wireless. 3 went well but the 4th bombed with that message. They source and destination locations were the same and were certainly well under 256 characters.

You may have a USB chipset that doesn't like very large files.

 

Well, let's ask the OP to post the path here for both the sourceand destinations.

I am still troubled by the use of "backupfile" in the message.
How does Windows Explorer know that the file is a "backupfile"?
Is TI hijacking the Copy foperation for the TIB file type?

 

Try using ReadFile to read the file,

In the program:
1. Set a large buffer size.
2. Check BOTH options.

If that works, rerun the program, but uncheck the Unicode option.

 

I am using Window Explorer "Copy and paste" function and the name of the file is "backupfile.tib" which is the name I used when do the backup with ATI. There is no problem with file I can browse window explorer. I don't think name of the file has problem because explorer tell me is around 20 minutes for paste.

thanks,

Rocky

 

Use the ReadFile program to see whether the file can be read.

 

I used the "ReadFile" program the error appear on the "Read#6, error on read"

I checked both on the first attempt and the error fall on "Read#" and also the unicode uncheck the same result.

Is that mean my backup is containing errors.

thanks

rocky

 

One thing you might try, would be to
Open Explorer and right click on the filename
then, Choose the Send To option and
then point to the desired destination device.

If the destination device is not listed on the send to listing, it can easily be added via a shortcut addition.

 

The error means that the number of bytes read from the file did not match the number of bytes that Windows thinks are in the file.

When you ran the program, the display lists the file, followed by whatever Windows thinks is the file size.

This is followed by 1 line for each read, listing the number of bytes read for each read.

In your case, the discrepany was found on the 6th read.

 

I just used ReadFile to read a 29 144 914 944 byte TIB file using a 128MB buffer (134 217 728 bytes).

This required 218 reads, with the last read pulling in 19 667 968 bytes.

All ReadFile does is read bytes, it has no idea of the type of the file.

The error that you got means either some bytes got lost at the end of the TIB file, or the file structures were inconsistent, which caused the 6th read to return 0 bytes, which would cause the ReadFile program to issue the message you received, as the total bytes read were not equal to the number of expected bytes in the file.

It is of course possible that Windows returned the wrong number of expected bytes.

My opinion is that the next step would be to pay a data recovery service, such as OnTrack, to determine whether the TIB file is recoverable.

Whatever you do, do NOT use ANY software that writes on the drive.