What is a Unix Executable File? Why is it doing this?

Greg_Reez

Greg_Reez

Registered
From time to time when I recieve files from clients, my mac calls them a kind of file called a Unix Executable File. When I look at the kind of file in Finder or "Get Info", it says its a Unix Executable file. Most of the time I know exactly what kind of file it is, a font file, psd, ai, even a jpeg, so I can go to the program and choose File>Open.

From time-to-time I'm unsure what format the file is, so I can't necessarily go to the program and do a File>Open. I sound "incapable" when I go back to a client and asked them what format the file is in. I included a pic of my latest problem.

I received a Quark file from a client and the Quark file as well as the packaged fonts and some photos are coming back as Unix Executable Files... I didn't have quarkxpress so I had to go back to my client and ask what type of file it was... I hate doing that.

Whats going on?
 

Attachments

  • UEF.jpg
    UEF.jpg
    67.7 KB · Views: 47
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. 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 .doc extension to associate the file with Word.

One of two things happened:

1) The files originated from a Windows machine (or some non-Apple operating system) and no extension was put on the file. Windows machines know nothing of reading/writing Mac-compatible resource forks.

2) 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.

There's not much you can do to get around the problem without teaching the clients new tricks. 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... FAT32, NTFS both seem to do ok with it most times).

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.
 
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.
Click to expand...

These particular files came to me through email, in a zipped folder, and I downloaded them to my desktop, then extracted them. They typically come from the sender, to my entourage inbox, or my web browser mail. There isn't exactly a lot of detail involved that I can give you. And they aren't always zipped files. If it is a jpeg, and I know it is a jpeg, but it doesn't have a file extension included, I can add the jpeg extension and it'll open up fine when double-clicked on.

At least I have an "idea" of whats happening, this time is a little more frustrating than most since they are font files and I can't install them to view the client's file properly.
 
Problem is (more or less) obvious: Unix programs are

1. Files that do not have extension (or they are named "a.out", but since there can be only one a.out, they are either renamed or compiled already using a different name)
2. They have execution ("x") mode on, which means they can be run

Since Windows knows nothing about execution mode, files in ZIP archives normally end with execution mode on.

Following worked fine: I copied a JPG file (a photo of my grand father's old smoke sauna) to file with no extension ("img") and put its x mode on ("chmod +x img). Now, Finder thinks it is Unix excutable file.

But, when you check the file type using "file" command on Terminal.app, it says: "img: JPEG image data, JFIF standard 1.01". This is because file command tries to read the file content, and check what the file really is.
 
Hello, i have got a similar problem. Someone did some filming and saved it on to a memory card. And they said all i need to do is transfer the clips on to my mac. But i can’t seem to do that as it will not open and where it says kind of file it says ‘unix executable file’. I’ve never importing film this way I’ve always done it from a DVCAM straight to my mac. I’m a little confused and have no idea about file types ect. I just want to play the clips on my mac, choose which ones i want then put them into final cut pro to edit them. I would be soooo grateful if anyone could help me!!!

:)::angel::::love:::D:eek::p:):confused:
 
ElDiabloConCaca said:
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. 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 .doc extension to associate the file with Word.

One of two things happened:

1) The files originated from a Windows machine (or some non-Apple operating system) and no extension was put on the file. Windows machines know nothing of reading/writing Mac-compatible resource forks.

2) 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.

There's not much you can do to get around the problem without teaching the clients new tricks. 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... FAT32, NTFS both seem to do ok with it most times).

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.
Click to expand...

I would like to thank you for the info that directed me to figure out what happened and how these files come to be on my mac. I was copying music to a Micro SD card that is in Dos format or FAT 32. While copying the folders in groups from my SSD in Mac OS Extended Journaled format, the folders with no extension were turned into the Unix Executable file with zero bites. I went back to the SSD and copied again the files to my SD card telling it to replace the file with the ones from the SSD and I had my music back in folders that contained my music
 
You must log in or register to reply here.
Back
Top