Using aliased file imports in project templates. Bug?


I’m using Scrivener to write adventure modules for tabletop roleplaying games. To save me some work I created a project template that has all the reference materials (e.g. rule books) linked als file-aliases (!) in the reference material section of the project file.

I then created a new project from the newly created template. My problem is now, that in the project all the aliases are no longer working although they are still “there”. The PDF-icon with the little alias arrow is still there but when I click on one, instead of displaying the PDF I only get a “gray” working space.

I investigated a little further and opened the *.scriv package in finder. I found out, that Scrivener seemed to have changed the aliases to numbered, empty (file size = 0kb) PDF-files. No wonder, they displayed as a “gray” working space.

To be a little more on the safe side, I replicated the behavior by starting from scratch with a new, “Blank” project file, just added one random PDF (or PNG, or JPG-picture, doesn’t matter) as an alias. Saved as project template, created new project from template. -> Same behavior.

The question is now for me: Am I doing something wrong, or is this a bug in Scrivener and if that is the case: Am I the only one using this feature?

I hope, someone can help me out. I really wanted to keep the filesize of the template low. If I have to add all the PDF’s as files, it will get pretty big. Since I will have many project files of the “adventure module” kind over time, that would not be a good solution.

Thanks in advance for the any help!

Best regards,

P.S.: I’m using version 2.3 (19120) of Scrivener (NOT the app store version) on a MacBook Pro (mid 2010) running OSX Lion, all updates installed (Lion and Scrivener).

P.P.S.: Sorry, if my english is a bit “rusty”. I’m no native speaker, I’m german. :slight_smile:

I just found the following entry here in the board. Same problem?

Hmm, curious, I can reproduce this. When creating a template, the project data gets compressed using the command-line zip utility. It seems to be this that is destroying the alias information (I can reproduce this using “zip” on the command-line). I’ll look into it, thanks.

Thank you very much!!!

If I can do anything to help, some further tests or something like that, don’t hesitate to ask.

Keep up the great work! Scrivener rocks!

This probably means that zipped backups also suffer from this bug. You might want to un-check the option to compress the backups until this issue is resolved.

Hmm, I played a little bit around with commandline utilities to compress and uncompress. I also could replicate the bug in the “zip” tool, but finally “ditto” did the job for me.

To compress a folder, just use for example:
ditto -c -k --sequesterRsrc --keepParent ./zipthisfolder

To uncompress you can simply use for example:
ditto -x -k ./myTargetFolder/

Aliases seem to get handled properly by using that.

Hope this helps, but probably you already knew that, didn’t you? :wink:

Hi Heiko,

Actually, Ioa just beat you to it. :slight_smile: Ioa looked into this yesterday and came to the same conclusion - that ditto would be better for backups and templates. So I have it on my list to address this for the next update, calling on ditto instead of zip. (This may be the 2.4 update rather than the 2.3.x update that will add Mountain Lion support, given the limited time left until Lion is released, though.)

Thanks and all the best,