cp / ditto / Finder copy caught in inifinite loop?

Question

Level 1

0 points

cp / ditto / Finder copy caught in inifinite loop?

Hi,

Hoping somebody can put me out of my misery here! I'm trying to copy mounted network drives (smb mounted from a windows XP box using Finder) to my shiny new iMac.

Initially I tried copying my d: drive in Finder and then used cp in Terminal, but found that both of them soon consumed ALL my ram (~1Gb) and had to be quit.

I then used ditto on a different drive (my y: if you're wondering!) and it worked great, no memory leaks, I used the -nocache option presuming that Finder and cp failed because they were trying to cache all the copied files.

But then when I returned to copy d: with ditto, it got caught in an infinite loop trying to copy a CVS repository. Finder copy also eats all my ram copying seemingly simple directories with ~20 files. I don't know if the two issues are related (i.e. is Finder trying to cache an infinite list of files?)

Whats going on here? I'm not impressed with OS X's interaction with SMB mounts!! I can kludge up a copy by logging into windows and scp'ing the Mac, but this doesn't solve the problem with cp / ditto / Finder copy on the Mac.

I heard Macs were great! I've had nothing but trouble so far...

stock 20 inch iMac (5 days old), Mac OS X (10.4.8)

Posted on Jan 11, 2007 2:39 AM

Reply

Answer 1

Jan 11, 2007 12:00 PM in response to davidceo

Hi David,
I am unable to reproduce your problem and I don't recall any such problem being reported here. The fact that it affects three different utilities suggests that the problem doesn't lie in the utilities themselves. It's possible that the problem is in system routine that all three use but that would seem unlikely given that the problem doesn't occur with other SMB volumes.

Thus, I would say that the most likely culprit is the windoze filesystem itself. UNIX commands have a builtin mechanism for avoiding infinite loops in the directory structure but I suspect that this mechanism is set in motion when the command stats a hard link or a symbolic link. However on an SMB mount, a windoze "shortcut" doesn't stat as any type of link so I'm guessing that your filesystem has an infinite loop on it and the limitations of SMB prevent UNIX tools from avoiding the trap.
--
Gary
~~~~
In theory, there is no difference between theory
and practice. In practice, there is.

Reply

Answer 2

davidceo Author

Level 1

0 points

Jan 12, 2007 2:14 AM in response to Gary Kerbaugh

Hi again,

After a little more investigation, the directories that failed to copy (causing infinite loops over a handful (~16) of files also refused to allow an 'ls' operation on them (perhaps for similar reasons). One of the directories causing the problem had only JPEG images (albeit 9000 of them!), I can't see what is causing the problem.

I decided to give smbclient a chance (I hadn't, thinking that Finder used Samba to do the mounting). To my surprise smbclient allowed me to backup the entire drives very quickly (over firewire) and suffered none of the issues I'd had previously (using 'prompt','recurse','mget *').

The only issue is that the modification times for the files is not preserved (but thats minor, I didn't see an option to preserve them).

So, does Finder use Samba to perform the smb mounting? If so, I can't understand the problems I'm seeing with copying / listing files. 'Wonky Windows Server' might be the only answer!?

Reply

Answer 3

Jan 13, 2007 10:00 AM in response to davidceo

Hi David,
I have a different but well known problem mounting shares of certain versions of Windows. It's been my experience that the Finder fails while the command line succeeds. I don't know how the Finder mounts SMB shares but I assume that it uses Samba just because I know of no other mechanism. However, Apple is particularly bad about documenting proprietary stuff so the Finder could use a proprietary library without us knowing about it.

If the Finder uses Samba, it must configure it differently because it certainly behaves differently. I gather that you used smbclient, which doesn't actually mount the drive. It uses the SMB commands implement an FTP style interface. I use that on Sun systems that can't mount SMB shares. However, OS X can mount SMB shares so it would be interesting to know if you get better results mounting via the command line, with mount_smbfs. (or mount -t smbfs) If that works, it may be worth noting that AppleScript seems to behave more like the command line than the Finder and if you "open" the webloc file associated with a "favorite" for which you saved the password in your keychain, that username and password will be used.
--
Gary
~~~~
But Captain -- the engines can't take this much longer!

Reply

Answer 4

davidceo Author

Level 1

0 points

Jan 15, 2007 3:42 AM in response to Gary Kerbaugh

I will have a few more investigations into the issues before I give my windows PC to my parents. I can't imagine I'm the first person to have seen these issues, it'd be nice to find a solution for them. Copying from mounted windows volumes onto the Mac should be straightforwards, I can imagine alot of people just gave up and bought external drives to share the data.

Beyond these issues the Mac is a fantastic piece of kit. So well designed compared to a PC. I have bootcamp and windows XP running now (I don't have a mac license for office!), definitely the best of both worlds.

As a further note for anyone searching how to copy files from windows to the mac, smbclient will preserve file time info if you write to a tar file instead of a directory (see 'man smbclient 'for how to do this). Definitely the most robust backup solution I've found so far.

iMac Mac OS X (10.4.8)

Reply