Do I have to rename thousands of music files/folders? // PROBLEM SOLVED! //

I have a 3TB music collection on my 2nd gen. Drobo which I have tried to copy to my new Drobo FS. However, it all gets corrupted after a while and I have to delete the share and start over, not being able to check which file/folder names are causing the errors.

After reading a lot on Droboshare support etc on smb issues with non-latin letters etc I fear that I have to rename several thousands of file and folder names?? All the Japanese titles, Brazilian, French, and German and Scandinavian umlauts, and titles with question marks etc etc.

Could you please shed some light here? I would really like to keep my Drobo FS, but if I have to go over all 200 000 song titles and change characters here and there… then I guess I should switch to Drobo S instead?

Mac or PC?

Sorry, Mac OS 10.6.4. All 200 000 song files tagged and arranged in iTunes.

If you are on Mac then you can mount the FS using AFP, which I think ought to solve your naming issues. In fact, I thought that with latest Dashboard and latest firmware AFP was the default.

You could try unmounting the share from Dashboard, then mounting it in Finder using command-K and trying a test copy of some files you know had a problem.

Well, I certainly took for granted that AFP was default, too. (And I have the latest Dashboard firmware.)

How do I check if it mounts using AFP?

However, as I actually CAN import SOME files and folders with special characters, I guess it actually DOES use AFP by default. It seems that the Drobo FS just have problems with some oft those files. But the randomness of it is frustrating and quite scary. My old Drobo Gen. 2 has no problems whatsoever. So the big question now is, should I stick with the FS and try to work things out, or should I switch to Drobo S instead…

You can use “mount” in Terminal and look for afp like this:

vm-harrisoni:bin ian_harrison$ mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
afp_2gbgV53qINvH1MXBJ72MHMtO-1.2f000003 on /Volumes/Shared (afpfs, nodev, nosuid, mounted by ian_harrison)

You can also do command-I in Finder on the share and look for afp: in the Server: name.

Thanks. I have checked and it is mounting using AFP.

As I have checked several random special-character-files/folders and all have been working, how can I find the ones that are causing the problem?

The thing is, the second time I tried to copy the iTunes Music folder to the Drobo FS, the system not only crashed, one of the five Caviar Green drives turned red and had to be replaced – and the part of the folder that had already been copied could not be accessed, and the share could not be used again. So I had to delete the whole share, replace the failing drive, and start over – without knowing which files/folders caused the problem.

So is there a way to find this out without first copying them to the Drobo FS? While they are still just in my old Drobo?

Finally, the error code when the copying process was aborted was “error -36”.

I have found the files that was denied by the Drobo FS. It was some miscoded Hungarian in some of my Bela Bartok collection, and a file in a J-pop album – but it was not the Japanese signs, they are no problem at all, but J-pop song titles often have odd special characters thrown in just for fun, and in a song called “Kiss me” there was a heart (!) between the words… I did not even know such a sign existed. And my Drobo FS seems to take music very seriously and did not approve of this.

The error-36 has not occured again, since I put in a new drive. Everything – finally – just works.

This is, as it seems, one of the characters causing Drobo FS to abort my music library collection:


Now how about that!

Share the love … oh wait … NOT! :stuck_out_tongue: