Dodgy cp command on drive copying

I've just taken the plunge and started upgrading my no. 1 empeg to a 40G capacity. Anyway, I've followed the FAQ instructions implicitly and came across a small problem. I decided to copy all my fids from the old drive to the new one and found the command shown in the instructions doesn't work. A quick BBS search turned up a thread discussing this very topic. To cut a long story short, my empeg is now copying the fids using:

cp -auvfx /drive1/fids /drive0/

Is there any reason why this isn't in the upgrade instructions?

I think Tony wanted us first to all agree on which switches to use...
I did some serious disk juggling & copying back and forth when upgrading and at the same time moving from a MkI to a MkIIa, and all I used was cp -ax

didn't need -f since I had cleaned out the destinations previously
same for -u
didn't want -v since I didn't sit by the empeg while copying, and output sometimes can slow down the process... Probably not much of an issue in this case since each file is pretty large and therefor the overhead pretty small...

/Michael

What I was trying to say was that the command shown in the instructions didn't work, at all. I needed to use the other commands to get the thing to copy. All I got otherwise was an error saying the argument list was too long...

My only complaint about "cp -auvfx" is that it fails to create any required "empty directories" on the target. Or at least that's what it used to do for me.

ml

By the command in the instructions I take it you mean
cp -v /drive1/fids/* /drive0/fids

'Argument list to long' is a limitation in the shells command line parsing/management, IIRC. The fids/* expands to a list of all tunes and tags files - which can be quite a lot. It's normally addressed by copying smaller batches ( ie first all files where the name starts with 1, then those who start with 2 etc...) This has been mentioned on the BBS and should, IMHO, be in the FAQ if it's not. Tony?

cp -auvfx /drive1/fids /drive0/ (and variations) solves this by stepping up one level and then pointing to a single entry, the directory containing all the tunes & tags files, instead of listing all the individual files. cp then recurses down into the directory, the list of files is then managed by cp directly, instead of passing through the shell.

/Michael

I'll make a note of this for future reference...
Thanks for your help. The empeg survived the transfer and I'm currently uploading all the albums I didn't have space for on the old drive

I was unaware that the command listed in the drive upgrade guide was in error. I do not know Linux and was going on what others have told me.

I am changing it now to:

cp -auvfx /drive1/fids /drive0/

If any of you Linux-heads disagree on this, please hash out the results and let me know what the consensus is. Since I know nothing about Linux, I depend totally on this BBS to supply me with information in that area. If you guys sit and argue about something in a thread and don't reach a resolution, I can't ever update this information in the FAQ.

Fair enough

/Michael

I think that was me that had the hard time copying such a large number of files... Thanks again to everyone that helped out.

Yes, although my efforts were sort of wasted as I ended up sticking the old 20G drive in empeg as well. So I finally have a 60G empeg. Woo-hoo!

In reply to:

---

'Argument list to long' is a limitation in the shells command line parsing/management, IIRC.

---

It's slightly deeper than that - it's a limitation of the exec() system call of the kernel, that the shell uses to start the cp process. No change you could make to the shell can increase the maximum argument list. Sorry!

Short of making the shell smart enough to know how/if it could chop up one call into multiple calls...

Thanks for the clarification - learn something new every day.

/Michael