1

We are creating a SCORM package (zip) and uploading to our Blackboard test instance and if one developer (will call him Bob) creates the zip and uploads then all everything works great. Myself and one other developer have packaged up the zip and uploaded it and a particular js file gets a 404 ("The specified resource was not found, or you do not have permission to access it") error when we try and run the application.

If Bob sends me his zip and I upload it to Blackboard it works fine and if I send Bob my zip and he uploads it then it fails, so I am pretty certain that is is an issue of the zip creation. I have looked at the zips and they look identical in terms of file structure.

3 questions:

  • Is Blackboard known to have particular problems with zip details? These do look like valid zip files.
  • Are there logs in Blackboard that describe the unzipping process that Blackboard uses when it installs a new SCORM package?
  • Is there a way to look at the deployed files/dir structure of a deployed SCORM package?

I am relatively new to Blackboard so if I missed something obvious I apologize.

Matthew Nichols
  • 4,866
  • 4
  • 41
  • 48

2 Answers2

1

I don't know any specifics about Blackboard's SCORM handling, but if your ZIP is smaller than 100MB you can test it for free at SCORM Cloud. They have a really great parser that will alert you if there is anything unusual or malfunctioning in your SCORM package. It will also let you inspect the package contents.

If it's just the one file that throws the 404 or 403, I'd check the security settings on the file. If they're too restrictive, the file may be physically present in your ZIP, but blocked from rendering by the server (hence 403) or maybe even blocked in the initial upload by the LMS (hence 404) due to insufficient privileges. I've had this happen a few times, typically on files that I downloaded from the interwebs (esp via Chrome's "Save As" file menu option) or on files I received from others.

If you're on a Mac and not a Terminal/chmod kind of guy, the easiest fix is to apply the containing folder's permissions to all enclosed items. ("Get Info" on the containing folder, then click the lock at the bottom of the Get Info window, then click the cog drop-down menu and select "Apply to enclosed items".)

pipwerks
  • 4,440
  • 1
  • 20
  • 24
  • 1
    Just going to add that one person in the office here using a Mac has exactly the same problem - and it's something to do with how it creates the zip - even taking a zip that I've created, and extracting + re-zipping creates an unusable content pack... – Rycochet Apr 04 '16 at 08:16
0

We discovered that it was a path casing issue; on one of the machines the working copy of the file in question had a mix of upper and lower case in it's name and the script tag that referenced it had an all lower case path. We suspect, but can't be certain, that the server where we are running on received an update that made the http requests path case sensitive. But it may have been that way all along and one of us devs messed up out file names.

Matthew Nichols
  • 4,866
  • 4
  • 41
  • 48