Mac server to PC server

[ripit]

we are in the process of moving all work to a new PC server from and old Mac server. i noticed that the first few jobs we have lost the ability to double click on a file and have it open in the proper application, all the files are showing up as a "Unix Executable File". What am i missing to have these files display and open correctly?

 

[KevinC@EFI]

we are in the process of moving all work to a new PC server from and old Mac server. i noticed that the first few jobs we have lost the ability to double click on a file and have it open in the proper application, all the files are showing up as a "Unix Executable File". What am i missing to have these files display and open correctly?

Macs don't use the file extension (i.e. file name) to determine the program used to open it. Instead, that info and more is stored in a "resource fork". That can't be saved properly on a Windows file system by default. I use a Linux server (Ubuntu), and even then it's a real pain to get it to work seamlessly - you have to emulate a Mac server, especially for using it for Time Machine backups, etc. (sharing over AFP instead of Samba/Windows Networking).

There may be solutions for it to work on Windows, but I'm not aware of what they would be, sorry! Google may be your friend.

EDIT: this link may be helpful to you or your IT folks, but read the whole thing first. http://en.wikipedia.org/wiki/Resource_fork


Kevin.

 

[Joe Duffy]

Use Exrtreme Z-IP to solve this issue.

 

[steveko]

Use Exrtreme Z-IP to solve this issue.

We use ExtremeZ-IP here with multiple servers, serving over 250 Mac users. It's a necessity (not cheap)

 

[Paint]

We have all Windows servers here, if your sever supports AFP
then your Mac's will work flawlessly...

 

[curveto]

we are in the process of moving all work to a new PC server from and old Mac server. i noticed that the first few jobs we have lost the ability to double click on a file and have it open in the proper application, all the files are showing up as a "Unix Executable File". What am i missing to have these files display and open correctly?

You didn't mention if the old Mac server was an OS X system or Classic Mac (i.e., <= OS 9). At this point in time there aren't many Classic Mac systems still hanging around so I'll assume you have the former.

Mac OS (all versions) have always split files into what amounts to two parts. This differs from ALL other platforms (Windows, Linux, etc.). With the introduction of OS X the file structure changed from a single file comprised of a Resource Fork (think "half" or "portion" or "region") and a Data Fork to TWO files (one for each fork described above). Like this:

Classic Mac Forked File (ONE file)...

-start- (byte 0)
file descriptor/resource fork header/etc
resources
...
data
-end- (byte N-1)

OS X Split File*s* (TWO files)...

File: .Foo.pdf
-start-
file descriptor/resource fork header/etc
resources
...
-end-

File: Foo.pdf
data
-end-

The content historically located in the Resource Fork moved to a hidden file with the same file name as its sibling but with a "." (dot) pre-pended to the filename. If you just copied files across from an HFS (Mac) volume to a Windows (NTFS or Fat32) volume you should now see BOTH files. They are both present on OS X too but the dot file is hidden (you can set some switches that show them but there isn't much point).

99% of the time the "dot" files will be empty and can be ignored (even discarded). They are designed to contain material that used to reside in a Classic Mac file's resource fork. OLD Applications (i.e., exe) routinely had resources but MOST data files (PDFs, etc.) had nothing in their resource fork (with one noteworthy exception I'll mention later). NEW Macintosh applications (designed for deployment on OS X) have evolved into a THIRD representation. Namely, a "bundle."

You need not know anything about bundles, per se except for the fact that they are actually a folder/directory that contains a tree of sub-items (e.g., executable files, resources, data ... you name it). Essentially everything that appears to be a single application "file" in the Applications folder on a OS X system is actually a bundle. Bundles, dot files and data files (i.e., non-dot files that contain data) can be moved across any file system. OLD (i.e., forked) Classic Mac files CANNOT be safely moved across non-Apple HFS file systems without using special tools (you will loose the resource fork material, if present).

So the "files" you think of as a user (e.g., PDFs) are actually the non-dot files you see on your Windows file system.

EXAMPLE: A PDF on Windows made by a Windows tool will (generally) be *identical* to a PDF file made on OS X (talking non-dot file file, btw).

If you didn't do anything bizarre when moving files they will all be well formed and should be useable. However, one piece of information that was kept in the resource fork was File Information that described file type and creator (i.e., the application that created and therefore owned it). This information actually provided an advantage that most non-Mac users took (and still take) for granted. Namely, the ability to open a file directly into its parent application via File->Open or by the common shortcut idiom of double-clicking on the file in the Mac OS "Finder" application (regardless of the file's type).

Finder is to Mac as Windows Explorer is to Windows, btw.

Most Classic Mac applications didn't give a hoot about overloading file names with extensions (e.g., .pdf) to describe "file type." OS X muddied this line quite a bit and when you mix that with Windows use of extensions the world has largely shifted back to employing file extensions as a type indicator.

IF a dot file is present and it contains viable File Information an application can explicitly respond to that (in conjunction with events from the Finder) to act like Classic Mac systems did. Unfortunately, many applications no longer do. IF they do they absolutely need viable/present dot files (so in this case you *can't* delete them). A safe rule of thumb is if the dot file is empty (size 0) you can safely remove it (it will be re-gened if necessary). Otherwise, leave them alone.

On Windows those dot files mean nothing. The file extension (along with some separate extension to exe mapping ... also present on OS X, btw) is everything.

What aspect of file usage norms broke for you?

We can help more if you give a specific example of a behavior that used to work but no longer does. (perhaps it's double-clicking on a file?)

A critical piece of the puzzle is that IF the dot files are present AND they have file information Mac OS X systems WILL use them (by their presence alone) regardless of the file system type (e.g., HFS+, NTFS) where they reside. If someone deletes the dot files OR they are empty (usually the issue) your Mac apps will act like Windows apps and TIFFs from Photoshop won't necessarily re-open into Photoshop via double-clicking.

There are ways to deal with things (via mime and file extension to application association adjustments) to get you where you want to be. If you broke stuff you can probably find an AppleScript utility or (bash) shell script that will fix things (at least partially).

PS - ***As long as your old Mac server wasn't a Classic Mac***, don't let anyone tell you that just because you moved files from a Mac server to a Windows server that they won't work (i.e., you must use an Apple Server or vis versa). That is a stereotype-class answer. The truth is more subtle.

PPS - You may also search for a Windows service/driver called MacDrive. This will let you mount HFS+ filesystems directly on Windows boxes and may provide a solution to your issue.

 

[Dave Thornton]

We have all Windows servers here, if your sever supports AFP
then your Mac's will work flawlessly...

... except file names will be limited to 32 characters.

 

[Dana Cowe]

I've had to perform the very same tasks, and had great success with a simple tool called "FileMonkey". It automates & simplifies the conversion of all the "Data Fork", "Resource Fork" complexities, and yields files that are Windows-ready.

Dana
DCA Consulting
DCA Consulting - Digital Document Automation Specialists
800-553-6764

 

[prepressguru]

You can work with SMB on a windows server just fine. But from the original post some info is missing. How did they copy the files from one server to the other? If they used the PC to copy the files from the mac then this might be the problem. The resource forks as mentioned would be screwed(missing). Also it is not clear how they are mounting the volumes. If the workstations are using 10.6 they may have to edit the way the resource files are writing to the SMB volume and how they can be read/seen as well.

Good luck, p

 

[prepressguru]

We have all Windows servers here, if your sever supports AFP
then your Mac's will work flawlessly...

Not if the workstations are using 10.6

p

 

[schenkadere]

Use Exrtreme Z-IP to solve this issue.

+1 I've used it for years...great product...great value.

 

[Jim-CompuDoc]

Prepressguru has it right. Use a Mac worksation to copy the files from the mac server to the pc server, and all will be well.

Do not copy them directly server to server.

Do not use a pc to do the copy.

 

[ripit]

Sorry for delay getting back to everyone, here is some updated information
Old mac server running 10.3.9 copy to new Windows server. They way I copied the files is using a mac workstation running 10.4.11, files on new PC server view and open correctly, however all mac workstations running 10.6 will not view and the ability to double click is not available. we mount the new PC server from the mac via SMB://. Do I need different setting in the new mac OS?

 

[Shawn]

There is a difference in how older style 10.4 machines and 10.6 handle bundling resource forks on SMB servers. Has to do with the named streams setting.

You could either re-copy the bad files from a newer machine that’s not using apple double on the resource forks or try turning on named streams on your older machines (or try turning them off on 10.6).

I know that turning them on works on 10.5 but haven't tried it on 10.4. In the long run it's better to use them going forward since that's the default with 10.6 and later.

This Apple Knowledge Base article outlines how to activate or deactivate them.

Mac OS X v10.5, v10.6: About named streams on SMB-mounted NAS, Mac OS X, and Windows servers; "-36" or "-50" alerts may appear

Shawn