redconfetti
commented
9 years ago As a solution to this issue, should anyone else stumble upon it, I recommend simply creating the directory and file that it intends to find. This example is of course for those using a local filesystem:
$ mkdir -p /Users/jasonmiller/Projects/canvas-lms/tmp/files/0000/0164/
$ cp tmp/canvas/user_provision-2015-04-24-1a813bd36c82617d-users.csv /Users/jasonmiller/Projects/canvas-lms/tmp/files/0000/0164/user_provision-2014-12-15-ae0da1cee526fdc4-users.csv
kzahel
Disclaimer: This is not a bug report, but just documenting a possible issue others may run into so they might find this in search results.
In my local Canvas instance that I've been running for quite a while I recently started to get this error when our LTI application would attempt to perform an SIS Import of a single user into Canvas via the SIS Import API.
It would successfully import the course and section SIS Import files, but it would fail when our course creation LTI tool attempts to import a single user (the instructor officially associated with the course). I took the same file, renamed it 'users.csv' and put it in a ZIP file, then used the web based SIS Import interface to import the same file, and it worked fine. But still during the automated process using the SIS Import API it would fail with this error.
I traced the issue down to the Attachment model, which uses the customized Attachment_Fu gem. The AttachmentFu#uploaded_data= method is responsible for obtaining the temporary file path for the attachment depending on the type of object passed to the method. In our case we're dealing with an ActionDispatch::Http::UploadedFile object. This method applies the contents of the temporary file to a Digest::MD5 object so that it can generate the MD5 hash that represents the contents of the file. It then looks for existing files that use the same MD5 hash.
This is very clever as it cuts down on unnecessary file duplication. If an existing attachment with the same MD5 hash is found, it associates the duplicate attachment with the current attachment. This results in the after_save callback that is called when the Attachment is saved to NOT copy the temporary file to the local file storage area, but instead expect the system to rely on the root attachment object to point to a file with the same contents.
I'm not sure why this is, but in my case, it turns out that the root attachment it associated with was providing a full file path that points to a directory and file that does not exist. This duplicate attachment was from an SIS Import I performed back on December 16, 2014.
I recommend adding a check within the 'if existing_attachment' conditional block that assigns the root_attachment to the object IF the file is actually present for the root attachment that was found. This would make for a better failover, and avoid this circumstance should SIS Batch import attachments become missing / lost from S3 or the local filesystem in the future for whatever reason.