Also if you are connecting to a Novell server via Novell's Mac Native File Acces (NFA - without the Novell client) There is a 31 character limitation with file names. But of course this is not a Novell issue it is an AFP issue. NFA uses the Mac's native file sharing protocol AFP which has this 31 character limitation. The strange thing about this is that the Novell server itself as well as any Mac server does not have this limitation. It only becomes evident when tranfering files to the NFA enabled Novell server or any Mac server using AFP. Microsoft Windows does not have this limitation because Novell's Windows NFA uses SMB.

The current version of Native File Access for Macintosh (with NetWare 6.5) actually does allow for long file names as it supports the current version of AFP (version 3). NFA on older versions of NetWare (5.1 and 6.0) only supported AFP version 2.2, which did have that 31 character filename length limitation.

As for the problem with filenames including a #, I'm able to copy files so named from my OS 10.4 Mac to one of our NetWare servers, so perhaps this could be an issue with an older version of NFA and NetWare on the sever.

Since our move to OS X and the addition of Linux and BSD servers to our environment, we have placed a restriction on allowed characters to be used in naming files: ? [ ] / \ = + # < > ; : " , | * are not allowed. Not everyone breaks something currently, but this is just future proofing for us.

Just because it's an available key, doesn't mean you should use it in the name of your document.

<quote>
? [ ] / \ = + # < > ; : " , | * are not allowed.
</quote>

Here at our College campus, it comes down to the end users just not knowing that they shouldn't use those characters. When they get an upgraded computer, we copy their document up to a Windows server. Sometimes there be files with date in their names, (6/3/2006). We have to locate each one and change the file names. Even though we tell the faculty not to use the characters afterwards they still do.

On a side note, Microsoft Office v.X and 2004 breaks this rule. They have three AppleScript items in the "Entourage Script Menu Items" folder; "Create Event from Message\cE", "Create Note from Message\cN", and "Create Task from Message\cT". You can find these files in your Microsoft User Data folder in Documents. I know MS just wanted an easy way to add keyboard shortcuts for these but you would think that MS would use the Customize Keyboard menu option that's available in any of their other Office Applications. That's just piss poor programing.

> That's just piss poor programing.

On the other hand, Microsoft wrote Entourage for the Mac, not for Windows.
I mean, it's very frustrating for programmers and users of Mac OS when they get asked to limit what they can do with this OS just because of Windows' own limitations. After all, if you use a Mac, it is to do more than you could do with Windows! ;-)

BTW, can't you copy your users' documents to a HFS+ disk image on the Windows server? This way, you wouldn't have any problem with filename compatibility.

Yes, mounting an HFS+ disk image from the serving on your Mac and then copying the files to the mounted disk would work. Up until the point when you need to get to the files from a Windows computer. And turning on Windows File Sharing on the local Mac doesn't help either.

I just ran a test with 2 folders and 2 files. The folders and files appeared just fine on the mac but from Windows the ones with illegal characters had garbled file names:
Folders: (Mac -> PC)
Hello -> Hello
Hello/ -> H0MUWZ~3
Files: (Mac -> PC)
Hello.rtf -> Hello.rtf
Hello.rtf/ -> H0MUWZ~3.RTF

Just a small rant here: while most of us here can be proud that we "know better" than to use problematic characters, the best solution is for the computer OS and apps to just let us use any character.

I used to think of Mac OS as more tolerant in that regard, and I hold out hope that the old-fashioned idea that "some characters can't be used in file names" will eventually go away.

---
--
osxpounder

Are there any Applescripts or programs that will automagically go and find these 'bad' characters and replace them?

Novell server has this bug, since the first release, and they appear not to be motivated to solve this. The problem occurs with any special character used also, as c-dilla, accented letters, etc., from other languages.

I know this bug for at least 6 years. I have reported it several times to Novell.

I think the big question is, why would anyone want to use Novell anyway? Yerg.

I can confirm this issue DOES NOT exist when using MAC OS X client 10.4.5 and Netware 6.5. We are connecting via NFAP over AFP. Upgrade your software, then complain if the problem still exists. Don't spread FUD.

I've observed a similar phenomenon sporadically with the Prosoft client versions 1.2 and 1.3 both. It seems every 2 to 12 copies or so, I get an error -36 or error 42. Usually, retrying the copy attempt immediately is successful. I'm not sure you even have to use any special characters in the filenames.
g=

Try Kopymac. I'm not sure it will work with all the characters but some it will convert.

I have troubleshot this issue with Novell Development and the problem appears to be caused by the version of NSS that is included with NetWare 6.0x. If you need to copy files containing special characters in the file name to a NetWare 6.0 server using AFP (via Native File Access), use a "traditional" volume on the NetWare 6.0 server rather than an NSS volume and you shouldn't see any problems. Also I can confirm that the problem does not happen on NetWare 6.5 NSS volumes (at least SP3 and later support packs).

Hi,

We have a Netware 6.5 with SP5 + Post NSS5a and had a similar issue and found the following.

1. To support file names > 31 chars, Netware creates a link to a file with a #. To verify this create a filename > 31 chars and have a look at this file via a OS9 Machine. You will see "teatasdfasfdasdf asfdasdfasdfdsaf.txt" appearing as teastadd#121111.txt"

and if you try to drop a file with #121111.txt in any other folder you will get an error.

Have already reported this error to novell today.

Thanks
Richard Martins
IT Dept
WA Newspapers Ltd
Perth
WA