Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have an old Mac-server that our marketing department uses as a File-server for several Mac Clients. I want to get rid of it for several reasons:

  1. Our primary backup system does not support the Mac Server
  2. Our AV solution does not support Macs
  3. No Mac Admin skills in IT.
  4. The server needs to be upgraded, due to age and capacity issues.

What I'd like to do is present a Share from either a Windows or an HP-UX server. However the existing files use characters that are invalid on the other OS's. We could write scripts to rename them, but we are concerned that the files are linked to other files internally, and renaming the file would break the link (think of an HTML file that links to a JPG, rename the JPG, and the link is broke)

So how do we rename the files, while preserving the linkages? Is there a better way?

The Mac-Server is OS X Server 10.0, I'm not sure about the clients, but they are newer (about a year or two old).

share|improve this question
What characters are invalid under HPUX? The only ones I'm aware of are the virgule and NUL. What OS are your Mac client running? What network file system protocol are they using to access the existing file share? – wfaulk Oct 9 '09 at 21:39
Could you add some informations regarding the versions in question? Is the server ancient (OS X Server 10.0 or even OS9)? What about the clients? – Sven Oct 9 '09 at 23:00
Aren't the links between files going to break when you migrate them to a different server anyway? – Zoredache Oct 9 '09 at 23:26
@Wfaulk: They frequently use / in dates in the filenames. HP-UX is going to want to treat them as subdirectory delimiters. @Zoredache, I'm told the links are relative so as long as the structure is the same, I should be OK. – BillN Oct 9 '09 at 23:54
@ SvenW: Added Version info – BillN Oct 9 '09 at 23:56
up vote 1 down vote accepted

You say filenames have slashes in them, and those are … hard to support under Unix. But Mac OS X is Unix. But HFS delimits directories with colons and not slashes. So how does this all play together?

On my SnowLeopard installation, I can create a file in the Finder that has a slash in the filename. When I look at that file from the command line, though, that slash has been transformed into a colon. If I create a file on the command line whose filename contains a colon, it gets transformed into a slash in the Finder. I cannot create a filename with a slash from the command line, and the Finder refuses to put a colon in a filename.

If I create a filename on a Unix Samba server that contains a colon, when viewing that file mounted on my SnowLeopard machine, I get craziness. The file "1:2.txt" gets transformed into "14V9MB~M.TXT". If I create a file on that share from the Mac, the colon gets transformed into three unprintable bytes: 0xEF, 0x80, 0xA2. This would appear to be the UTF-8 encoding of U+F022, which is in the Unicode "private use area", which means it is not universally defined.

If I do the same tests using a real Windows machine as the server, I get similar results, I think. Windows won't let me use either a colon or a slash in a filename. If I create a filename with a colon from the Mac side, Explorer shows me the file without any visible character in the colon's place at all. (That is "1:2.txt" shows in Explorer as "12.txt".) From the command line, a dir shows me "1?2.txt". I suspect that it knows how to interpret the UTF-8 encoding, but doesn't know what to show for that private-use character point.

What I think this all comes down to is: you can make the transition as long as you can figure out how to translate slashes in filenames into 0xEF80A2. This is obviously testable.

share|improve this answer

Just yesterday I had a similar issue in that I needed to copy files from our Mac server to a Windows workstation, where I wanted to try and work on them. After much stuffing about fixing the filenames (e.g. to get rid of the forward slashes) I did indeed discover internal links broke in the process. This became such a mess that I abandoned the idea.

For what it's worth, it's really not too hard to learn enough of the basics of Mac server if all you're using it for is a file server and it's not public facing (security is another matter). For that matter, doesn't at least on of your Mac users have enough admin skill to help out there? It seems to me that you're wanting to get rid of the server for what on the face of it appears reasonable reasons, yet are prepared to have Mac clients which you can support no better that the server. Am I missing something there?

You mention antivirus software as a problem on the server but don't mention it with respect to the clients. To my way of thinking it needs to be on both or don't bother with it on either. If you have something on the clients, can't you use the same thing on the server? I personally don't use it on the Macs, only on Windows (this may of course change in the future).

share|improve this answer
The Mac clients are supported by a third party. But since the server lives in the dataceter, it will become IT's issue if anything happens. If the marketing group wasn't asking to buy a new one, then I'd be inclined to learn enough and let it go. If we need to spend money on it, I'd rather spend the money increasing the SAN capacity, and carve out a chunk for marketing there. – BillN Oct 14 '09 at 20:27

If this is a relatively new Mac machine you can mount the share via NFS to a Unix/Linux machine and copy the files to it without too much hassle. By mounting via NFS I've been able to migrate offices that were using strange characters locally to network setups. You can also HFS partitions on any modern Linux system.

If this is an OS 9 server you may be in some trouble-OS 9 didn't support NFS natively and after some googling I can't even find a project to support reading OS 9 partitions.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.