Odd USB drive problem

I have a Vipower USB mobile rack with a 300gb IDE drive enclosed that's
formatted NTFS, used to backup important files for storage off-site. Once
per month I update the files using a batch file (4NT) using this context for
the copy command:

COPY D:\TIFBAK\*.* L:\TIFBAK /U /S

The problem is that it hasn't updated the files since 09/2007 even though it
would show file-copy progress and lots of disk activity as if it was being
done. Thus, I thought I was backing up the files but in fact was not, and
it seems to be unable to hold more than 118gb in that folder. After running
the batch file, which appears to be adding files, the total used capacity of
the drive does not change, suggesting that no files are being added.
However, if I repeat a given copy command manually (e.g., COPY
D:\TIFBAK\FILENAME.ZIP L:\TIFBAK) I'm told the file exists and asks if I
want to overwrite it. It in fact doesn't exist, as it doesn't show up using
DOS DIR command, in Windows Explorer, or Windows file search. The files
copied are typically 20mb-1gb in size.

This problem persists whether using the batch file, doing a COPY command in
DOS, or using Windows Explorer to copy the files. OTOH, if I move all 118gb
existing in the \TIFBAK folder to the root of that drive (L:\) there is no
such problem going beyond 118gb and all files are copied successfully.

My D: drive, a 500gb SATA drive in the computer also has a \TIFBAK folder
which is the first-level storage device for these files, and there is no
such limitation--so I'm convinced it isn't an NTFS capacity problem. Is
there a USB interface or driver issue that prevents >118gb in a folder under
the root directory? I've solved the problem by changing the batch-file
commands to L:\ as the destination folder, but I would like to know what's
going on with this. I've been thinking I've been backing up my files and
for five months have not!


--

"Bob Davis" <nospam RemoveThis @nospam.net> wrote in message
news:Estsj.528$aj7.214@newsfe20.lga...
>I have a Vipower USB mobile rack with a 300gb IDE drive enclosed that's
> formatted NTFS, used to backup important files for storage off-site. Once
> per month I update the files using a batch file (4NT) using this context
> for
> the copy command:
>
> COPY D:\TIFBAK\*.* L:\TIFBAK /U /S
>
> The problem is that it hasn't updated the files since 09/2007 even though
> it
> would show file-copy progress and lots of disk activity as if it was being
> done. Thus, I thought I was backing up the files but in fact was not, and
> it seems to be unable to hold more than 118gb in that folder. After
> running
> the batch file, which appears to be adding files, the total used capacity
> of
> the drive does not change, suggesting that no files are being added.
> However, if I repeat a given copy command manually (e.g., COPY
> D:\TIFBAK\FILENAME.ZIP L:\TIFBAK) I'm told the file exists and asks if I
> want to overwrite it. It in fact doesn't exist, as it doesn't show up
> using
> DOS DIR command, in Windows Explorer, or Windows file search. The files
> copied are typically 20mb-1gb in size.
>
> This problem persists whether using the batch file, doing a COPY command
> in
> DOS, or using Windows Explorer to copy the files. OTOH, if I move all
> 118gb
> existing in the \TIFBAK folder to the root of that drive (L:\) there is no
> such problem going beyond 118gb and all files are copied successfully.
>
> My D: drive, a 500gb SATA drive in the computer also has a \TIFBAK folder
> which is the first-level storage device for these files, and there is no
> such limitation--so I'm convinced it isn't an NTFS capacity problem. Is
> there a USB interface or driver issue that prevents >118gb in a folder
> under
> the root directory? I've solved the problem by changing the batch-file
> commands to L:\ as the destination folder, but I would like to know what's
> going on with this. I've been thinking I've been backing up my files and
> for five months have not!
>
>
COPY doesn't have a /S or /U flag, it does have a /V for verify.
Should you be using XCOPY? That does have /U & /S, but only copies files
that already exist.

Mike.