• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Moving large files (size and numbers)

wxjunkie

Senior member
I put a new 30 gig hard drive in my machine and when trying to transfer from my old hdd to the new one, Windows will lock up after maybe 500 megs of transfer. I've tried in Win98, Win2000, and XP (all of which I have installed on my box). Anyone know of a different/stable/faster way just to transfer files from one hdd to another? I've got about 25 gigs of stuff to move.
 
You can try not moving the files at all. Just stick all the hard drives in your box all at the same time.

Alternatively, use Linux. Linux never, ever locks up.
 


<< You can try not moving the files at all. Just stick all the hard drives in your box all at the same time.

Alternatively, use Linux. Linux never, ever locks up.
>>


Damn, thank you Mr. Wizard. Talk about problem solving. Oh and escarcot, FWIW Linux can lock up. I'm sure wxjunkie appreciates your trolling in his thread.

wxjunkie, are both hard drives installed in the same computer or are you tranferring across a network of some sort??? It sounds as if you have some bad sectors/hard drive problem or a bad NIC. Give a little more information.
 
Psychoholic: They're both in the same machine. The sector problem may be the answer because it just started happening when I reformatted the hard drive that I am transferring to.
 
I would perform a detailed surface scan of that disk and see what shows up. FWIW worth there's a possibility that it's the controller itself but usually the controller goes out completely. See what you find and just ignore the troll.
 
Believe it or not, no problems were found with a thorough scan. When I transferred the files originally from the old to the new hard drive for backup purposes, everything was fine, but now that I've reformatted the old one, and try to move everything back, it just won't work. Any idea how to check the controller? Both hdd's are on the same channel.
 
Try installing Linux and moving the files using Linux and if Linux locks up then call me a troll, otherwise call me a smart guy who gave you a working solution.
 
I'm not moving partitions around just to move some files. This hdd problem is not necessarily a Windows thing, because the lock up only happens one way, I've tried moving all files back from the old hard drive and it worked fine, no lock up. Some Linux fiends need to stick to their OS, maybe work on a decent front end instead of using Windows as an excuse for every computer problem that arises.
 


<< I'm not moving partitions around just to move some files. This hdd problem is not necessarily a Windows thing, because the lock up only happens one way, I've tried moving all files back from the old hard drive and it worked fine, no lock up. Some Linux fiends need to stick to their OS, maybe work on a decent front end instead of using Windows as an excuse for every computer problem that arises. >>


Decent front end found, take your pic: ksh, sh, bash, csh, ash, zsh, etc etc 🙂

But can you move smaller amounts of the files around, say 300MB without problems?
 
exactly.....

Yeah I can basically move all the files I want until total transfer nears a gig, then I get a stack dump.
 


<< exactly.....

Yeah I can basically move all the files I want until total transfer nears a gig, then I get a stack dump.
>>



I know this only solves part of the problem but try moving less than that maximum amount, reboot, move close to that maximum amount, reboot, etc. And I wouldnt trust either disk at this point. What are you using for an ATA controller? Updated drivers? Its a strange problem...
 


<< Personally I'd be pulling sticks of memory too, I've seen bad ram do similar things. >>



Haha, bad ram can do some funky things...
 
Lucidguy:

Trying to put the blame for the problem on Windows just shows your vast incompetence and laziness. Rather than trying to diagnose the problem, you take the easy way out and blame Windows, a typical and lame response that I am growing more and more tired of seeing.

I personally run batch files on NT and 2000 boxes almost every day that move HUNDREDS of gigs of data, and they have never locked up, blue screened, or otherwise puked all over themselves.

Linux is a good product, but it is a niche product. So is Windows--it just so happens that the bigger niche for consumers is an OS that do much much more than be a rock solid web server.

So rather than attempt a lame assimilation of all windows users to your point of view of the linux OS, why dont you next time try to actually solve the problem. That way, we might not think of you as a obnoxious loudmouth who really posseses no useful computer skills.
 


<< I put a new 30 gig hard drive in my machine and when trying to transfer from my old hdd to the new one, Windows will lock up after maybe 500 megs of transfer. I've tried in Win98, Win2000, and XP (all of which I have installed on my box). Anyone know of a different/stable/faster way just to transfer files from one hdd to another? I've got about 25 gigs of stuff to move. >>



Have you tried booting to pure DOS and using XCopy32?
 


<<

<< I put a new 30 gig hard drive in my machine and when trying to transfer from my old hdd to the new one, Windows will lock up after maybe 500 megs of transfer. I've tried in Win98, Win2000, and XP (all of which I have installed on my box). Anyone know of a different/stable/faster way just to transfer files from one hdd to another? I've got about 25 gigs of stuff to move. >>



Have you tried booting to pure DOS and using XCopy32?
>>



That would probably work, and I would wait the hours that I know it would take using that, but the only problem is, it doesn't support long filenames. I have way to many files with long filenames that I would never be able to sort out if I used xcopy32.

Does anyone know of a DOS app that somehow supports long filenames? Obviously the console does, but I need pure DOS apps.
 


<<

<< exactly.....

Yeah I can basically move all the files I want until total transfer nears a gig, then I get a stack dump.
>>



I know this only solves part of the problem but try moving less than that maximum amount, reboot, move close to that maximum amount, reboot, etc. And I wouldnt trust either disk at this point. What are you using for an ATA controller? Updated drivers? Its a strange problem...
>>



Not sure about the controllers, but the motherboard is an Abit Kt7-RAID
 
You could try booting into Win2k and use xcopy.

From a command prompt, type xcopy /? to see all the switches.
 


<< You could try booting into Win2k and use xcopy.

From a command prompt, type xcopy /? to see all the switches.
>>



Tried that, still get a stack dump.
 


<< I personally run batch files on NT and 2000 boxes almost every day that move HUNDREDS of gigs of data, and they have never locked up, blue screened, or otherwise puked all over themselves. >>



You've been lucky. But your day is coming. The inherent instability and countless bugs and backdoors in Windows/IIS products are known even to little kids. The day that you lose hundreds of gigs are data is maybe tomorrow, maybe closer than tomorrow. Hope you have good backups.



<< So rather than attempt a lame assimilation of all windows users to your point of view of the linux OS, why dont you next time try to actually solve the problem. >>



I did offer a solution to his problem. My offered solution is to use Linux's world-famous rock-hard-stable filesystem code to do the transfer. You may not agree with my solution, but you have no right to say that I offered an illegitimate solution. I strongly believe that my offered solution will work.
 
I think you are experiencing the via 686b secondary IDE problems. Try putting one HD as the master and one as the slave of the primary channel and try it again. Via bios and driver fixes don't seem to solve the problems with their 686b chip fully, so the only know full proof way to bypass the bugs is to not use the secondary channel of the IDE controller.

If you are using the raid connections, then try updating to the latest drivers.
 


<< Personally I'd be pulling sticks of memory too, I've seen bad ram do similar things. >>


Good call Soybomb. I had overlooked that as an issue.



<< I did offer a solution to his problem. My offered solution is to use Linux's world-famous rock-hard-stable filesystem code to do the transfer. You may not agree with my solution, but you have no right to say that I offered an illegitimate solution. I strongly believe that my offered solution will work. >>


Red Alert, Troll dead ahead....

You are right about on thing you did offer an illegitimate solution.

Linux never crashes, what a load or BS. W2K and Linux are both very stable OS'es but both are not crash-proof. I will say however that with both 99% of the time it's either a hardware or user problem. Linux is also not immune to security isses, lucid, or are you niave once again. This is aside from the fact it has nothing to do with his problem.

Quit trolling this thread unless you have something useful to add to it. I don't think anyone asked for your vulture vomit.
 


<< I don't think anyone asked for your vulture vomit. >>



I don't think anyone asked for your undue insults, either. You may disagree with my proposed solution, and you are welcome to civilly discuss why you disagree, but calling people names does not place you on higher ground. It places you on the playground along with all of your other low-IQ MCSE buddies.
 


<< Alternatively, use Linux. Linux never, ever locks up. >>



Not true. I've had it lock up. Seen it happen right there in front of me. Coincidentally, I've also had FreeBSD lock up (4.2-STABLE). So much for it being &quot;more robust than Linux&quot;. Interestingly, the third OS I tried on this particular machine (the NAT server for my house) was Windows NT 4.0 Server, and it hasn't locked up yet (4 weeks and counting).

I used to use this machine under NT4 Workstation for about 2 years from mid '97 to late '99 and I have the privilege of not having any BSODs during that time. Long live ECC memory and the 440FX chipset.
 


<< I don't think anyone asked for your undue insults, either. >>


Do I need to start pointing out insults you've directed at people, lucid. I didn't fire off without cause, but you have. So it wasn't undue. Do you need me to link you to some examples???

You know lucid a calculator doesn't lock up and probably runs about as much of his software as Linux does. I think the reason you haven't seen Linux lock up is due to the fact once you got it installed you turned the computer off and left it that way.

Now, unless you have a viable solution take your trolling elsewhere.
 
Back
Top