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.
