Game icons break when stored on Google Drive

[astrochili]

Hm, how it can be fixed? :)

[MaddTheSane]

This could be caused by two different things:

1. Google Drive isn't backing up the icon^m file that is added when folders (including packages) have a custom icon set.
2. Google Drive isn't backing up the resource fork of the icon file.

[astrochili]

Okey, it's not cool..

But I found some slack solution for those who store games on Google Drive for safety reasons, but not for sync reasons.

I re-import all games again, but in a local folder. Then I copy them to Google Drive, icons missing. After sync, I returned icons copying them and pasting in folder info panel. Google Drive has ignored these changes.

[alinebee]

Unfortunately custom file icons rely on OSX-specific metadata that isn't always roundtripped by syncing services (Dropbox used to have this problem too, not sure if it still does.)

There's two necessary components to these custom icons, and if either one gets broken then no icon for you. The first is the Icon^R file inside the root folder of the gamebox: this is a regular file but has a funny character in the filename that may prevent it from syncing correctly. The second is an OSX-specific flag on the folder saying "look for a custom icon inside this folder." AFAIK that flag is stored in the resource fork on filesystems that support forks (like HFS+) or in a hidden .DS_Store file in the parent folder for filesystems that don't (like NTFS).

Services like Google Drive would probably have to jump through extra hoops to sync resource forks, and they may decide to ignore .DS_Store files and the like altogether. This means other OSX-specific things like labels and Spotlight metadata will probably get stripped as well.

---

There's not really anything Boxer can do about this for regular gameboxes, as this feature is handled at the OS filesystem level. However this syncing problem doesn't affect games-as-standalone-apps, because apps get special treatment: their icon is read from a regular file inside the app bundle and no resource fork trickery is involved. So, you could wrap all your games up as standalone apps using the bundler.

(Custom filetypes can display previews, like you see on PDFs and movie files in Finder, and at one point I looked into making a preview generator for gameboxes that would load an image inside the gamebox. But it turns out that previews get a silly document-with-a-folded-corner frame that cannot be turned off and that looks dumb as hell when the icon is meant to be a game cover. So I decided to stick with custom icons.)

[astrochili]

Thanks for the answer, I would hope that someday cloud storage and OS X will be friends =)

I wonder why the icons disappear only during the first sync, but if you install them after sync manually - they remain. How about the idea to keep the icon in image file format inside the package, and when you run Boxer App automatically update it in case of problems with finding the Icon^R/.DS_Store files?

[alinebee]

I suppose after the gamebox (which is really a folder) has been initially synced then Google Drive will leave the folder alone and not touch it in a way that causes OSX to discard the metadata.

Actually if the Icon^R files themselves are surviving the syncing process, then Boxer could check at load time if that file exists but the flag is missing - and if it is then just reinstate the flag.

Could you check this for me? Sync a new gamebox that has an icon, let it lose its icon, and then run the following command in the Terminal: ls -la /path/to/the/gamebox.boxer/ If the Icon^R file is still present, then you should see an "Icon?" entry in the list.

[astrochili]

Unfortunately, after sync the Icon file is missing. Yes, file exist before sync.

[alinebee]

Welp.

So yeah. Boxer will currently generate a 'bootleg' CD/floppy-disk icon when you launch a game that doesn't have an icon, but it could also store a backup copy of the source image you used for your custom box art inside the gamebox to regenerate it in the same manner. That would make gameboxes even larger than they are already of course.

[astrochili]

Yep, I think backup copy of the source image / generated bootleg is good solution for situations with cloud storage. At the same time I understand that it is too rare problem. I'll try to figure the source code, and if the decision will be in a couple of lines of code, I'll be happy :)

Thanks for great app!

[alinebee]

For what it's worth, Dropbox exhibits the same problem. It does roundtrip other OSX-specific metadata (e.g. spotlight comments, labels), which leads me to suspect that like Google Drive, it's deliberately stripping the icon files out of the folders. Possibly this decision is because the \r character in the filename would be incompatible with some destination filesystems, and "sanitising" the filename would break the icon anyway.