How did these files specifically come to you? How were they transferred? Had they been compressed? If you can describe (in detail) the route they took from hard drive to hard drive, CD to CD, network to network, we may be able to pinpoint where, exactly, the resource fork info was lost and find a workaround. FAT32, NTFS both seem to do ok with it most times). They should use a compression (.zip usually works) that preserves resource fork information, or store the files on a file system that retains this information (MS-DOS format = yuck for resource forks. There's not much you can do to get around the problem without teaching the clients new tricks. Unzip an archive: Double-click the archive. Control-click or right-click files and choose Compress. Windows often associates a default program to each file extension, so that when you double-click the file, the program launches automatically. File extensions tell you what type of file it is, and tell Windows what programs can open it.
Zip multiple files or folders: Shift-click to select them. A file extension is the set of three or four characters at the end of a filename in this case. Windows machines know nothing of reading/writing Mac-compatible resource forks.Ģ) The files originated on a Mac, but were either transferred with a protocol or compressed with a program that ignores or strips files of that resource fork information. Zip a single file or folder: Control-click or right-click it and select Compress item name.
doc extension to associate the file with Word.ġ) The files originated from a Windows machine (or some non-Apple operating system) and no extension was put on the file. This doesn't happen with files with extensions most of the time, because even if a Word document lost its resource fork (type/creator codes, specifically) information, it could still use the.
What's happening is that Mac OS X can't read the file's resource fork (and, since there's no extension on those files either, it can't even "guess"), and therefore doesn't know what the file is.