Multiple users on one Hype file, data.plist, perhaps rambling

1

Hi there!

I’m writing today because we’ve just ran into an issue we’ve never experienced before.

Our workflow involves multiple people working on one Hype file stored on Dropbox in a day. Just now, a previously functioning file seems to have lost all or the majority of links to resources that also reside on Dropbox (i.e. none will “Update From Source”). I suspect that this is due to one of us opening a yet-unsyched version of the Hype file and overwriting changes. All makes sense there.

Assuming that this was a static file path issue, I opened up the appropriate data.plist file and, thinking that it would remedy the situation, found every instance of my colleague’s unique User folder and replaced it with my own, the end result of which was a filepath to the assets folder identical to my own Dropbox access. However, the unlinked assets in question were still unlinked when the Hype file was opened and demanded a re-link choice.

(Additionally, when attempting to manually relink items after this, they then disappeared from the Resources panel.)

We are fixing the issue for this deliverable by making image adjustments in the exported folder, but I would like to understand the problem more completely for the future. Is there some way I did not think of to resolve this kind of issue via the data.plist file as was my instinct? Is the only solution to have a strict check-out system for who updates links?

I hope this all makes sense.

Thanks!

2

Unfortunately the answer is pretty much yes.... .hype documents are stored as a folder and there is no way for Dropbox to atomically update this, so it is highly possible that the document state can get very much out of whack.

As for linked files, due to macOS security systems they have to be stored in the Hype document in a way that is machine-specific. It isn't based on a relative filepath but a "bookmark" record. Thus a different machine or user would ultimately wind up destroying the links. We find this to be hugely problematic but believe Apple may be relaxing some of the file system access restrictions in the future that could help with this problem.

The "Edit in" option of Hype v4 allows editing the resource in place instead of using the external links, which can be an option in some use cases but I know it doesn't fully solve the workflow.

1 Like
3

Thanks Jonathan. So, should I also understand this to mean that a network file server would also not fix this issue, as the bookmark limitation would still be in effect?

4

Unfortunately that is correct.

1 Like
5

Roger, thanks!