PDA

View Full Version : Long File Name Problem Between OS X Server & Windows Server




GilGrissom
Jul 24, 2007, 05:40 PM
Hey guys.

I've just received a phone call of a friend of mine who is having a bit of crisis at work regarding a Mac server. Basically they're trying to copy over large amounts of files, from the Mac server to the Windows server and it keeps coming up with the error "bla bla bla File names too long". The Windows server is running NTFS, while the OS X server obviously HFS+.

I know from some background that the Windows file formats do not like long file names, so I presume this is the problem. But it seems too easy to come across that I was hoping that there is a solution or work around to the problem?

That's where you clever clogs come in...the eternal holy grail of Mac knowledge!

I'm hoping someone out there hears this plea and can help!

Any thoughts?

Thanks guys.

Sorry if this seems a little sketchy in details, it's what my friend only gave me as he spoke full of panic over the phone! Rightly or wrongly it's not doing much to strike confidence with Apple into this company's mind.



RZetlin
Jul 24, 2007, 05:41 PM
Why not just rename the file to a shorter name?

GilGrissom
Jul 24, 2007, 05:45 PM
Why not just rename the file to a shorter name?
They have gigabytes, at least, of stuff to transfer...it's not practical at all to rename them all.

mkrishnan
Jul 24, 2007, 05:47 PM
I think this has to do with the Samba protocol, although I'm not sure. I know the issue also shows up when Remote Desktop Client mounts a local MacHFS+ disk onto the server computer.

Some off the cuff suggestions...

- script to zip or tar the files and then unzip / untar... long filenames inside archive files survive.

- Use an AFP client on Windows to bypass Samba.

- Use external drives to ferry the files

GilGrissom
Jul 24, 2007, 05:50 PM
Thanks mkrishnan. Those sound like great starting blocks. The external drive idea sounds most straight forward. I'll pass all these on.

Keep the mind-mapping coming!...

After G
Jul 24, 2007, 06:04 PM
I remember hearing once that Windows' 255 character length limit includes directories when counting characters, so if you have something in OS X like a really convoluted directory structure and then a long filename exceeding 255 characters in length Windows would choke on it. Don't know if this is what's causing the problem but it might be.

You can try to shorten the directory structures by rearranging them on the Apple side if this is the case.

You can also try to copy to a folder at the root of the drive you are moving the files to on the Windows side and see if that shortens the path+filename length enough.

mkrishnan
Jul 24, 2007, 07:52 PM
I remember hearing once that Windows' 255 character length limit includes directories when counting characters, so if you have something in OS X like a really convoluted directory structure and then a long filename exceeding 255 characters in length Windows would choke on it. Don't know if this is what's causing the problem but it might be.

I've heard of this issue too, and I think this is actually a different issue, because the maximum name length is always the same. It seems to affect a number of network file sharing activities between Macs and PCs -- as mentioned, Samba, RDC, and WebDAV is another one affected by it. The programs either prompt you or replace the trailing part of the filename with a hashcode in the filename. I'm not sure if the problem lies in OS X or in Windows or what, although I note that in my three examples, three different technologies from three different vendors (Samba implemented by Apple, WebDAV implemented by the Goliath team, and RDC implemented by MS) all result in the same behavior.

jolster624
Jul 10, 2008, 11:12 AM
Just stumbled upon this. I know it's an old post, but hopefully this could still help. The problem is the Appleshare version that Windows is still using as a service. If you do a Connect to Server with the IP alone xxx.xxx.xxx.xxx, it would default to AFP. Try connecting smb://xxx.xxx.xxx.xxx

:cool:

Kebabselector
Jul 10, 2008, 05:04 PM
I remember hearing once that Windows' 255 character length limit includes directories when counting characters, so if you have something in OS X like a really convoluted directory structure and then a long filename exceeding 255 characters in length Windows would choke on it. Don't know if this is what's causing the problem but it might be.

This is true, we've recent had the same issue with a migration from Novell to Microsoft. Nothing to do really other than rename files/folders.

We found large folder names nested inside other folders. O.k. one other big pain in the arse is the fact that word will let users save a filename that is the first line/paragraph of the document.

/ooops didn't check the original date of the post :bolx:

cue82
Jul 23, 2008, 12:28 PM
check this site out, this might be the solutions for your problem

http://grouplogic.com/products/extremeZ-IP/

HiRez
Jul 24, 2008, 03:28 AM
You could also run an AppleScript or shell script which truncates the filenames, though you might have problems if any filenames truncate to the same thing, or if you run an app or database which refers to the files by their original name.

You also need to be careful about illegal characters, which are often different between filesystems. Avoid high ASCII characters too.

iMouse
Jul 24, 2008, 02:15 PM
Microsoft Robocopy works around long file paths and file names. I use it quite a bit to move terabytes of data around between Mac/Windows/Linux boxes.

1. Install Robocopy on the Windows box
2. Turn on Windows Sharing in Mac OS X
3. Map the folder on the Mac as a drive letter on the Windows box
4. Use Robocopy to move the data by pointing the source to the destination mapped drive.


Set the following options.

/V /FP /S /E /COPYALL /ETA /R:10 /W:30
Be sure to enable /LOG

Oh....and be aware that it runs as a ROBOCOPY.exe process and progress can be viewed by opening the log file. It will continue to update the log file as it works and will add a report at the end for any files that it failed to move due to corrupt data/file system/screwy characters. :D