MacOS – Unable to expand “.zip” into “downloads” (Error – 63 file name too long.)

It's likely that filename.zip is either not actually a .zip file, or is corrupted.

Open up Terminal. You can access it by typing "Terminal" into Spotlight.

Enter the command(s) in the steps below into your command line prompt (triple click the line, copy it, and paste it into your prompt). Replace filename.zip with the actual name of the zip file.

If the name of the file contains spaces, you need to enter it differently using the escape \ character. For example, if the file is named compressed crap.zip, you'd type compressed\ crap.zip in the command line.

Step 1:

Repair disk permissions. Once done, attempt to open the .zip file again. If you wish, you can do this from the command line.

diskutil repairPermissions /

Step 2:

Use file to confirm it's actually a zip file:

file ~/Downloads/filename.zip

The output should be: Zip archive data, at least v2.0 to extract

If you don't receive this output, post the output as a comment before proceeding.

Step 3:

After confirming it's actually a zip file, attempt to unzip it directly from the command line:

unzip ~/Downloads/filename.zip -d ~/Downloads

Step 4:

Step 3 will likely fail. Run the zip command to attempt to repair any corruption and salvage the contents of the archive (again, replace filename.zip with actualname.zip):

zip -FF ~/Downloads/filename.zip --out ~/Downloads/Repairedversion.zip

If it executes cleanly, you'll be directly returned to your prompt. Quit Terminal. Navigate to your Downloads folder and double click Repairedversion.zip- it should unzip without issue.

Alternatively, it may not exit cleanly. If you're presented with

Is this a single-disk archive? (y/n):

Hit the y key. After you're returned to the prompt, again attempt to open Repairedversion.zip from your Downloads folder. If you're still unable to open it, comment below with the warning(s) received from the command. If you've reached this point though, it's likely that the file is irreparably damaged.

I've tried creating a PDF file with that name on two machines and both immediately index the files and provide them in searches for any part of the name. I would be curious to the see the actual content of the file in case the content is somehow causing the indexer to fail, but then you say the indexes okay with shorter names, so it doesn't follow that the content is a problem.

Something you could do is try running mdls against the file. This should show you metadata that is recorded in the Spotlight index for the file. For example when I run it against the PDF I used for testing I get things like the following. You can see here the kMDItemDisplayName and kMDItemFSName are both pulled from the actual name of the file, as the document is just a random PDF about something else entirely that I simply renamed).

kMDItemAuthors                 = (
    se0896
)
kMDItemContentCreationDate     = 2014-12-11 11:38:01 +0000
kMDItemContentModificationDate = 2014-12-11 11:38:01 +0000
kMDItemContentType             = "com.adobe.pdf"
kMDItemContentTypeTree         = (
    "com.adobe.pdf",
    "public.data",
    "public.item",
    "public.composite-content",
    "public.content"
)
kMDItemCreator                 = "Microsoft® Word 2010"
kMDItemDateAdded               = 2015-03-22 22:30:07 +0000
kMDItemDisplayName             = "Hans-Jorg Oestern, Otmar Lorenz Trentz, Lorem Ipsum Lorem Vascular Injuries- Trauma Surgery I (European Manual of Medicine).pdf"
kMDItemEncodingApplications    = (
    "Microsoft\U00ae Word 2010"
)
kMDItemFSContentChangeDate     = 2014-12-11 11:38:01 +0000
kMDItemFSCreationDate          = 2014-12-11 11:38:01 +0000
kMDItemFSCreatorCode           = ""
kMDItemFSFinderFlags           = 0
kMDItemFSHasCustomIcon         = (null)
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSIsStationery          = (null)
kMDItemFSLabel                 = 0
kMDItemFSName                  = "Hans-Jorg Oestern, Otmar Lorenz Trentz, Lorem Ipsum Lorem Vascular Injuries- Trauma Surgery I (European Manual of Medicine).pdf"
kMDItemFSNodeCount             = (null)
kMDItemFSOwnerGroupID          = 20
kMDItemFSOwnerUserID           = 501
kMDItemFSSize                  = 132180
kMDItemFSTypeCode              = ""
kMDItemKind                    = "Portable Document Format (PDF)"
kMDItemLogicalSize             = 132180
kMDItemNumberOfPages           = 5
kMDItemPageHeight              = 841.92
kMDItemPageWidth               = 595.32
kMDItemPhysicalSize            = 135168
kMDItemSecurityMethod          = "None"
kMDItemTitle                   = "Job Title"
kMDItemVersion                 = "1.5"

Another thing you could try is running the manual import tool mdimport with the debug option against both versions of the file (i.e. the file with a long name and again with a short name) and check for differences in the data that is being extracted and imported into Spotlight's metadata stores. The following command (with the correct path to your file of course) should show you which importer is being used and which keys are being extracted. This might help diagnose the fault. This is also a way to force Spotlight to index (or reindex) a file, but I don't think I've ever found that to be necessary. NOTE: The easiest way to perform the following command is to type "mdimport -d 3 " and then drag and drop the file onto the Terminal window.

mdimport -d 3 /Users/USERNAME/Hans-Jorg\ Oestern\,\ Otmar\ Lorenz\ Trentz\,\ Lorem\ Ipsum\ Lorem\ Vascular\ Injuries-\ Trauma\ Surgery\ I\ \(European\ Manual\ of\ Medicine\).pdf"