SLS Copy Error Solved: Corrupted Google File Attachment Case

Recently, I encountered an interesting issue in the Student Learning Space (SLS) where a single activity in a module refused to copy. Other activities cloned without problems, but this one kept failing silently. After some digging, the root cause turned out to be a corrupted Google File reference inside that activity. 

This post documents what happened, why it happened, and how it was resolved—useful for educators handling Google Drive attachments in SLS.

What Went Wrong

SLS activities can include Google Drive attachments via:

Text/Media → Google File → Add/Embed File

In this case, the activity contained a Google File link that SLS could no longer access. Likely reasons include:

✔ The Drive file was deleted
✔ The file became corrupted
✔ The file was moved or ownership changed
✔ Permissions were restricted

When SLS clones a module, it must also duplicate or relink attached Google resources. If an attached file is invalid, the copy process may freeze or fail for that activity—similar to how Drive cannot preview or copy corrupted files.

How the Issue Was Resolved

The fix was surprisingly simple:

1. The corrupted Google File was identified

2. It was deleted from the activity or from the user’s SLS-linked Drive

3. A valid Google file was embedded in its place

Once the corrupted reference was removed, SLS successfully copied the activity like normal.

Why Other Activities Copied Fine

An SLS module is essentially a structured package consisting of multiple activities. Each activity may contain:

• Text components

• Questions

• Media

• Google files

• Other embedded resources

Only the problematic activity contained a broken Google resource. The rest:

• Had valid attachments

• Were fully accessible

• Could be duplicated without errors

So SLS happily cloned the rest of the module, and only failed where the broken link was present.

Behind the Scenes: How SLS Handles Google Files

When copying, SLS tries to:

1. Copy module/activity structure

2. Recreate native components

3. Duplicate or relink Google attachments

If any Google file cannot be accessed, step 3 can fail—blocking the entire activity from copying.

Key Takeaways

• A single corrupted Google file can block an entire activity from copying

• Deleting or replacing the corrupted file resolves the issue

• Other activities remain unaffected as long as their attachments are valid

Optional SOP for Future Cases

A quick troubleshooting checklist for staff:

1. Try copying the module/activity

   • If it fails, check attachments

2. Inspect Google File components

   • Look for broken or blank previews

3. Check Google Drive

   • Confirm file still exists

   • Confirm sharing permissions

4. Replace if needed

   • Remove corrupted file

   • Re-add a valid version

5. Re-copy the activity

   • It should now duplicate normally

This small but useful troubleshooting case shows how Google Drive dependencies can affect SLS workflows. If you handle Drive-based materials in SLS, it’s worth keeping an eye on file integrity and permissions to avoid silent copy failures.

Reference:

https://vle.learning.moe.edu.sg/my-drive/module/view/01dd849b-dbae-490d-8f98-e46858dba0bc/section/98550750/activity/98550754

https://vle.learning.moe.edu.sg/my-drive/module/edit/0cee81db-8539-47c5-8ea4-eee03fda40ba/section/98906378/activity/98907097