• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 40442
  • Last Modified:

"Not enough free disk space" error when copying 33GB file to empty 250GB Iomega network hard drive. (26GB copies fine.)

I am having a problem that has stumped me. I have a  33GB backup file (Friday.bks) on a 1TB network hard drive with embedded XP. I am trying to copy it to a 250GB Iomega network drive. When I do, I get the following error: "Cannot copy Friday: There is not enough disk space. Delete one or more files to free disk space, and then try again."

Here are some facts:

I can copy a 26BG bks file just fine.
Iomega does not use fat32 so the 4GB limit is not what is causing the error.
I have tried to copy the file from 3 different servers (all running Server 2003) all display the same error.
I have tried to use xcopy, drag and drop, copy and paste and they all give me the same error.
I CAN copy this file with my workstation (XP Pro) without getting any error.

The ultimate goal is to copy the file to the Iomega drive using xcopy in a batch file to be run from a server over the weekend.

Any help is appreciated.
0
entcee
Asked:
entcee
  • 28
  • 13
  • 9
  • +5
3 Solutions
 
Gary CaseRetiredCommented:
Sounds like disk quotas may be enabled on the Server 2003 systems.   Do you have administrative privileges on these systems? ... if so, change the quotas.   ... if not, see your system admin.

2003 also allows setting max file sizes (in fact Microsoft recommends 20GB).  You could also be encountering this limit.


0
 
SysExpertCommented:
Is the file compressed ?

Is their any metadata ?

You can copy it from your workstation but not from the Server ?

Strange. Is their any imaging  or other automated SW running in the background on the Servers ?

I hope this helps !


0
 
entceeAuthor Commented:
garycase:
I am the sys admin. When I log into the computers I log in as 'administrator'
We do not have disk quotas turned on (We do not use them)

SysExpert:
The file is not compressed, no metatada
Correct, I can copy it from an XP Pro machine but not using a server 2003 machine. (The file does not reside on the server or workstation, just tying to copy it from one network drive to another.)

The servers are pretty standard, a couple are domain controllers one is an Exchange server and the other is a terminal server.
0
Cloud Class® Course: C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

 
entceeAuthor Commented:
Where can I check this setting:
"2003 also allows setting max file sizes (in fact Microsoft recommends 20GB).  You could also be encountering this limit."
0
 
David_FongCommented:
Do you have enough temporary space available on the machine that you are doing the copy with?

Remember workstations often have big C: drives but servers are more likely to have small C: for the OS and big D: etc. for the data. 36GB is a common disk size for the OS mirrored disk pair of a server, which would normally have about 8GB used and explain why all your servers fail to do the job. You could set TMP and TEMP to be another drive but that may upset one of the applications. Perhaps you can run the command on the imbeddded XP NAS box using the WINAT scheduler or SOON.exe from the resource kit.
0
 
Gary CaseRetiredCommented:
The 20GB limit is recommended if you're using FRS;  I don't have 2003 and am not sure where the limit is set.   You can read Microsoft's recommendations for limits here:
http://support.microsoft.com/kb/840675/en-us#XSLTH3128121123120121120120

If you're not using FRS, I doubt this is the issue.

Although NTFS file sizes don't have any practical limit, some implementations (I can't find the reference -- but remember this from a couple years ago) have limits based on the cluster size.   Since you indicate your external drive is empty, it might be interesting to reformat it with 64kb clusters and see if the behavior changes.   I'd be a bit surprised if this works -- but seems worth a try.




0
 
entceeAuthor Commented:
I thought that this may be the case, however my workstation only has 14GB of free space and my server has 20GB of free space.

I can copy from the 1TB NAS to a different directory on the same NAS without issue so that points me to the Iomega drive. But then my workstation has no problem doing the copy so that points me to something on the server.

Unfortunately the NAS is pretty locked down. It has XP embedded but the company uses their own interface so I cannot run a scheduler, etc...

I am at a loss.
0
 
David_FongCommented:
It's not the right way to do it anyway, using the (x)copy on an an intermediate machine means that machine has to copy the whole file locally then copy it to the second NAS box, doubles the network traffic and the possibility of the copy job failing because the intermediate machine breaks down. Just run the job from the imbedded XP box or from the IOmega, kick it off from an intermediate server at most.
0
 
entceeAuthor Commented:
I have a feeling it has something to do with the way the Iomega drive reports it's free space or the way the server reads its free space.
0
 
entceeAuthor Commented:
David_Fong:
As stated before, there is no way to run the job from either network disk. the embeded XP is locked down with the manufacturers own interface. So in actuality you absolutley have to have an intermediate machine. I do not really care about the network traffic since we are doing it over the weekend when nobody is in the office. The network is virtually unused expept for weekend email traffic (incoming) If the server breaks (the intermediate machine), I have more problems than just a file not being able to be copied.

I doubt the intermediate machine need 30GB of free space to copy a 30GB file. Like I said in a previose post, my workstation has 14GB free and it will copy the 33GB file, the server has 20GB free and cannot copy it.
0
 
David_FongCommented:
I made my second comment before I saw your previous one. Sorry, should have clicked refresh, only a couple of minutes between our posts. Wasn't meant to be rude.

I have to experiment tomorrow on whether XP can cut/paste files bigger than the local free disk space, I only have win 2k at home and that certainly can't.
0
 
entceeAuthor Commented:
I know you did not mean to be rude. I hope I did not come accross as being rude either. This is just frustrating.

I have one server that only has 6GB free on one partition (c) and 8GB free the other (d) and it will copy the 22GB file just fine, but of course not the 33GB one.

I talked with Iomega and they do not know why either.

Let me know what you find.

0
 
two22Commented:
entcee

Any chance that HDD has been used with Symantec's Norton Protection or similar file protection software?

On another forum, a member was being denied access to his HDD, being used on a network, for lack of available space because Norton Protection had used up much of the HDD--but, no files showed up when viewing the HDD with Windows Explorer.
0
 
entceeAuthor Commented:
We are using Norton Antivirus but not file protection.
0
 
rindiCommented:
Just a shot in the dark, make sure the network drive you are copying to is defraged..., and use robocopy instead of xcopy. It is part of the resourcekit tools.

http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en
0
 
entceeAuthor Commented:
Well, there is no utility to defrag the drive and besides that, the drive is empty to there is nothing to defrag.

I will try robocopy but right now I am not even using xcopy, I am using explorer to try to copy the file with the same results.
0
 
rindiCommented:
Robocopy (the robo part comes from "Robust" copy) is much more robust than any other copy program I know for windows, and copying using explorer often stops somewhere in the middle, while robocopy just goes on.
0
 
entceeAuthor Commented:
I tried robocopy with the same result. Here is the error I get:

"2006-01-11 09:54:47 ERROR 112 (0x00000070) Copying File \\device\share\Friday.bkf
There is not enough space on the disk."
0
 
klancyCommented:
Are you by any chance running Enterprise Edition of Server 2003?
0
 
entceeAuthor Commented:
No, standard edition.
0
 
entceeAuthor Commented:
I guess we need to start looking at how server 2003 finds out how much space is left on a target drive before it starts the copy process. Anyone have any ideas?
0
 
Gary CaseRetiredCommented:
Just for grins, did you try reformatting the external drive with 64kb blocks?
0
 
entceeAuthor Commented:
Actuly the interface for the Iomega drive just has a "format" button there is no way to configure the block size.
0
 
Gary CaseRetiredCommented:
Interesting -- so a right-click, "format" option is not available from Explorer??
0
 
rindiCommented:
Can you post a link to the specs. / manual etc for the iomega device?
0
 
entceeAuthor Commented:
garycase :

You are correct. Right click does not show a format option. (Even when mapped)
0
 
Gary CaseRetiredCommented:
0
 
entceeAuthor Commented:
0
 
Gary CaseRetiredCommented:
... crossed posts ...

Basically the same specs for both links, however (but slightly different-looking drivers).

Shouldn't matter (the manual probably just isn't updated) -- but neither drive lists 2003 as a supported OS.
0
 
entceeAuthor Commented:
I was thinking that the requirements were only for their software (locator tool) etc... Do you think it is mis-reporting it's size to the 2003 OS?

When I look at the properties of the device in Network Places, it shows as a Windows NT 4.9 Server
0
 
rindiCommented:
This could have something to do with compatibility, as gary is indicating (2003 not in supported list). Have you tried an online chat session with iomega support? They do try to be helpfull...
0
 
Gary CaseRetiredCommented:
At this point it's anybody's guess; but it seems to me that for some reason there's a file size barrier in play here.   I'd guess it's at 32gb.   Just for grins, you might concatenate a couple of large files to create a file very close to -- but smaller than -- 32gb and see if it will copy fine.   Then add a bit to it to cross that threshold and see if you can't copy it.   Won't solve your problem -- but at least you'll know what the limits are.   Then, if you need to get larger files on the drive, just use a file splitter to split it into two files (and recombine them later on your XP desktop).

0
 
Gary CaseRetiredCommented:
... as rindi suggested, an online chat with IOmega's a good idea => they may very well be familiar with the issue and know how to resolve it (or they may just note that 2003 is not a supported OS for that device).
0
 
entceeAuthor Commented:
I did chat with them yesterday. They did not know why this was happening. Do you know of a program I can use to create files of different sizes with ease?

Here is the transcript of the chat session with Iomega:
Tom: Thank you for contacting Iomega's Online Support Services. Please provide the serial number of your Iomega drive if you have not already provided this information. How may I assist you today?
Nate: I have several Iomega 250GB network hard drives. How can I tell the amount of free space?
Tom: You you right click on the drive letter in My Computer and choose Properties.
Nate: There is no drive letter (We do not map a drive to it) it is a network drive. It is accessed by \\devicename\NetHDD\
Tom: You would need to map a drive letter to it to determine the capacity.
Nate: let me try....
Nate: OK, is there any other way to tell the free space?
Tom: The drive letter is the only way available through Windows.
Nate: OK. One more thing... Is there a file size limit? (What is the largest file I can copy to the drive?
Tom: With the default format (FAT32) there is a 4GB limit on file size. You can reformat to NTFS to avoid this limitation.
Nate: OK, so I just format the drive through a windows workstation or through the web insterface?
Tom: Yes.
Nate: which one?
Nate: I guess it does not matter, when I click properties it tells me it is NTFS. Here is the problem I am having....
Tom: Sorry for the delay -- you would format through the Device Settings area.
Nate: I can copy a 22GB file with no problems. Using the same computer I try to copy a 33GB file and I get an error stating there is not enough disk space (I just checked and I have 194 GB free. Do you know what could be causing this?
Tom: If the drive is in NTFS, the error should not occur. Are you able to copy this file from any other PC?
Nate: Actually yes and no. I am trying to copy this from any one of our 4 servers (server 2003) and it fails. If I try to copy if from my workstation (XP) it works. However, the server has no problems copying this 33GB file to other network hard drives.
Tom: What I would suggest is to try mapping the drive to a drive letter on the server 2003 machines and try the transfer. I am unsure of why this would not work given the conditions.
Nate: That is what I tried (mapping a drive) and it still fails.
Tom: Ok, do you have any antivirus software running on the server machines?
Nate: Yes, Symantec Corporate edition.
Tom: Is this also running on the XP machine?
Nate: yes, but of course the servers have the "server version" and the workstation has the workstation version. Basically they are the same though
Tom: The error really should not be occuring since NTFS would not have a problem with either a 22GB or a 33GB file. The only suggestions I could make would be to try the transfer with the antivirus disabled and try a reformat on the drive itself. You might also want to check all of the connections between the drive and the server 2003 machines. Also, try a larger file size than 33GB and see if you get an error.
Nate: OK, I will play with it some more. I will start another chat tomorrow if I still need help.
Tom: Is there anything else I can assist you with?
0
 
Gary CaseRetiredCommented:
... Well, that wasn't a very helpful chat (except it confirms IOMega doesn't know what to do either)

I've not used it with files as large as your 33gb file, but this has worked well with everything I've tried it on:
http://www.gdgsoft.com/gsplit/

Most "zippers"  (WinZip, 7-Zip, WinRAR, etc.) also support splitting their archives into smaller pieces.
0
 
entceeAuthor Commented:
The server(s) are seeing the size correctly. The is the result when I do a dir:

C:\Documents and Settings\Administrator>dir \\2d-osb\NetHDD\
 Volume in drive \\2d-osb\NetHDD is NetHDD
 Volume Serial Number is 0846-0FD4

 Directory of \\2d-osb\NetHDD

01/10/2006  12:09 PM    <DIR>          .
04/01/2005  12:05 PM    <DIR>          ..
01/10/2006  09:27 PM    <DIR>          1S-2850EX
01/11/2006  06:37 AM    <DIR>          1S-1600DC
01/11/2006  06:11 AM    <DIR>          1S-1400DC
               0 File(s)              0 bytes
               5 Dir(s)  190,287,183,872 bytes free

C:\Documents and Settings\Administrator>

I do have some files in the directories (from testing) It shows there is 190GB free so the 33GB file should fit.
0
 
rindiCommented:
Something else I'd suggest is to check on the iomega site for a firmware update. Maybe you'll have to get this through a chat again. I recently had a problem with a rev drive of iomega, and that was resolved with a firmware update I got to via chatting with iomega.
0
 
entceeAuthor Commented:
Yeah, I actuallly have 4 of these drives and 2 of them have an older firmware. I have asked Iomega for new firmware and they tell me it is not publicly available.
The drives that have the newer firmware have the same problem and Iomega says that that firmware version is the latest.

garycase:
I am weary of installing software to my servers but I will give Gsplit a try. I am glad it has command line options so it can be automated.
0
 
klancyCommented:
I, too, believe you're running into a bug based on a 32GB limit somewhere, but you folks have covered everything I could think of and a lot more.  And sometimes there's just no solving a bug.   How about a work around?  GaryCase - can you run two backup jobs to produce two backup files, rather than one 33GB file?  Than your XCOPY should work fine....   If someone's suggested this already, I apologize.  I've been trying to follow along while I'm working on something else and I've only scanned some of the comments.

Klancy.
0
 
entceeAuthor Commented:
Actually the file is 31.6 GB (33,978,439,680 bytes)

I just used 33GB since it is 33 million bytes.
0
 
David_FongCommented:
Would it be too much bother to put Backup Exec on one of the servers and see if that can copy the larger .bkf file? It treats ntbackup .bkfs as if they were its own as long as you define the folder the file is in as a backup to disk folder - and obviously create another B2D folder on the Iomega. You'd have to change the max size of B2D files or it would split the 33GB file into smaller ones.
0
 
entceeAuthor Commented:
Actually that is how we used to do it. We used to use NTBackup directly to these Iomega drives and it works without issue. I see that we have a bkf file that is 33 milion bytes on the drive that NTbackup created.

We have since changed things around. We purchased 3 1TB NAS devices for our on site backups and want to use the Iomega drived as an off site storage. We take the Iomega drives and put them in a saftey depost box once a week.

Since we already use NTBackup to do a backup to one of the 1TB NAS devices, I do not want to have to run it a second time to back up the same data on the Iomega drive. We just need a copy of a bkf file that has already been created.
0
 
David_FongCommented:
That's why I suggested using Backup Exec to copy them (not back up the .bkf but copy it) as BE treats it as a virtual tape to tape copy and therefore may use a different method of checking available disk space. More as an experiment rather than permanent fix since after 60 days you'd have to buy a license for it and you're obviously happy with the free ntbackup.
0
 
entceeAuthor Commented:
I am not using any backup software to copy this file, I am using widows to do so.

Even if I used Backup Exec, it would create a backup file that I would then have to copy over to the Iomega drive.
0
 
Gary CaseRetiredCommented:
Did you try GSplit yet?   Just curious if this resolves it.  (resolve might be the wrong word here -- but at least it should work around it)

0
 
entceeAuthor Commented:
I have not. Waiting to talk with the President to see if he is OK with that as a solution.
0
 
David_FongCommented:
>Even if I used Backup Exec, it would create a backup file that I would then have to copy over to the Iomega drive.

No, backup exec's native backup to disk format is .bkf same as Windows format so it can be setup to *copy* bkf files from one place to another. A backup of a bkf would require a two stage restore whereas a copy only needs a single stage restore.
0
 
entceeAuthor Commented:
The problem I am having is trying to copy the bkf file from one location to another. I am not backing up a bkf file, nor do I want to.
0
 
David_FongCommented:
I haven't suggested you backup the bkf file but BE has the ability to COPY .bkf files (and .bkf is the only file BE can COPY) although it's a bit complicated to set up the job.
0
 
entceeAuthor Commented:
Does BE not use "windows" to copy the file? Most applications would use the OS to copy the file since that functionality already exists in the OS. I could be wrong.
0
 
David_FongCommented:
It obviously uses Windows ioctls and APIs but it doesn't treat a bkf quite the same as a normal file if you inventory it and treat it as a tape, it copies them as it would copy from one tape to another. For example if the original BKF is 33GB in size and the max .BKF file is set to 10GB it would end up as 4 .bkf files on the destination just like copying a LTO tape to several DATs.
0
 
rindiCommented:
I use backup exec to backup to a rev, and it automatically uses a max file size of 1 GB, so I get many such files on the REV. But that works well.
0
 
entceeAuthor Commented:
***UPDATE***

I tried to use GSplit with not much luck. It was very problematic when trying to run it unatended.

I ended up just making a backup of the backup file. Since this is used for off site storage (in case of fire or other desaster) and will rarely (if ever) be restored from I do not mind having to restore twice to get the data.

I think using backup Exec would have worked but did not want to purchase it. (I also did not want to install it without knowing for sure.)

Doing a backup to the Iomega drive is MUCH slower than just doing a copy. (I can copy the 32GB file from my XP machine to the Iomega device in about 3 hours while it takes around 6 to do a backup to it. Not sure why.

Thanks everyone for your help with this.
0
 
Gary CaseRetiredCommented:
The longer time is most likely because of the management of the directory information.  Anytime you copy a file, the directory is updated - which requires both at least one extra seek (more if it's a lower level directory) and a directory write.  That's why copying a lot of files always takes much longer than copying a single file with the same amount of data => and also why reading a large number of files is much faster than writing the same set of files.

I've never used GSplit unattended -- I rarely need to split files; but when I've done so GSplit worked perfectly (but always in interactive mode).

I would simply set your backup program to use smaller "chunks" ==> i.e. perhaps 30GB ==> and then copying the individual pieces should work fine.   Doesn't resolve why this is happening; but should allow the copies to work MUCH faster (since copying a single large file will involve a trivial number of directory writes and far fewer seeks.
0
 
entceeAuthor Commented:
Found out something interesting...

The file that I can not copy can be moved.  As long as I move the file, it does fine. Just cannot copy it.

Strange :/
0
 
Gary CaseRetiredCommented:
Yes, strange indeed.   Especially since the "move" command first copies, then deletes !!
0
 
rindiCommented:
Have you tried disabling AV software while copying?
0
 
entceeAuthor Commented:
Yes, tried it with no change.

Oh well. Moving the file will be fine for what I will be doing, I just wish I could figure out what was going on.
0
 
Gary CaseRetiredCommented:
Found a few references to other instances where copy & move had differing results.   Didn't see anything definitive, but did find a discussion about the API's for these operations having fundamentally difference behavior -- don't know for sure how accurate that particular thread is, but it would explain what you're seeing.   According to what I found, a "copy" is just that -- it copies the file;  a "move" was described as analogous to shredding a paper before copying it => i.e. each major allocated block was copied, then destroyed.   To quote:  "... the equivalent of sending the original paper through a shredder..."

I've never dissected the Move & Copy binaries to confirm their behavior, so I don't know how accurate that is; but it would explain why Move is working for you & Copy isn't ==> but of course still doesn't explain why Copy doesn't work.
0
 
David_FongCommented:
Neither of these will help but they do show up the difference between copy/paste and move (which probably uses cut/paste). Of course you're more servicepacked than these and I'm not hot enough on the difference between MoveFileEx and CopyFileEx or whatever they use underneath to move data about nowadays.

http://support.microsoft.com/kb/870979/en-us
http://support.microsoft.com/kb/259837/en-us
0
 
Roetzel_AndressCommented:
I just got done trouble shooting this issue and resolving it. Robocopy on large jobs uses page file space increasing through the copy operation and does not give it back....that is unless you set your page file size large enough. Windows 2003 server sp2 up to date with 4 gig ram, dual duo core AMD. page file set at about 2-3 gig. 400 gig disk (direct storage, C:\) 1.8 TB SATA  storage array via fiber channel HBA. Ran into this issue repeatedly on a 600 gig copy to the 1.8 TB array. FInally did some monitoring. Task manager says Page file grew until it reached the limit and then came the not enough storage space available to process this command.  I set the page file at 100 gig just to make sure I had enough and then strangely enough the page file did not grow at all and copy operation went though all 609 Gigs without a hitch. Hope this helps someone out.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 28
  • 13
  • 9
  • +5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now