When I got back to my personal project recently and tried to commit some files to its Subversion repository, I started getting an
Abort Trap error message. At this point, I was told by Subversion that I needed to use
svn cleanup in the local copy and
svnadmin recover /My/Repository on the repository to make things right.
I couldn’t find anything online about other people having these problems.
So I decided, if the repository was bad, I would dump and reload it, and maybe that would fix the problem. I used the Subversion commands I described in this previous post to do it.
What I discovered was that the reload process halted at an “Icon” file. Actually, the name of the original file was not “Icon”, but rather “Icon\r”, where the “\r” indicated a carriage return a.k.a. ASCII value 13 character, which is the old Macintosh linebreak character.
As described at on this page (but curiously, nowhere that I could find on Apple’s ADC Web site), “Icon\r” files are the way to specify that the enclosing folder should have a custom icon, and to specify what that custom icon should be. Such files are invisible due to a particular bit set in their HFS information. Update: in the original version of this post, I said they were just the OS 9 way of doing this, but I was wrong; OS X still uses this technique for everything except volume icons. (Thanks, Uli!)
In any case, they must have been sucked into the Subversion repository I made. If I used my original repository dump file, I could even make the “Icon\r” files show up in the Finder, since the hidden bit is not preserved by Subversion. But any attempt now to commit any changes while these “Icon\r” files existed made my repository go boom. (Why didn’t this show up during earlier commits? Dunno that, either.) This included any attempt to delete those “Icon\r” files. I was stymied.
However, there was a way to modify the dump file I had been able to make (though not re-load). Subversion dump files are human-readable text files, but the file I had was 80 Mb., basically unreadable in any text editor on my machine without a lot more RAM. Luckily, the Subversion authors saw just this possibility, and made a utility,
svndumpfilter, that can be used to filter specific files out of a dump file.
This quote from the Version Control with Subversion manual explains:
Simply give it either a list of paths you wish to keep, or a list of paths you wish to not keep, then pipe your repository dump data through this filter. The result will be a modified stream of dump data that contains only the versioned paths you (explicitly or implicitly) requested.
See the rest of the manual for more details: it’s quite nicely written.
Using that utility, I was able to remove the “Icon\r” files completely from my dump file (as if they had never existed), load the repository in again, and go from there, with no loss of history for the files I hadn’t removed.
One nice thing was that once I’d removed the “Icon\r” files from the
trunk area of my repository, they were also gone from the one
tag area I’d made. I didn’t have to manually remove the files from both places.
Updated: made corrections suggested by Uli in the comments.
One thought on “Subversion Diversion: “Icon\r” Files Make Repository Go Boom”
annoying that that caused you problems. I’m glad I don’t have any custom icons on my project folders. A few corrections, if I may:
1) The traditional Mac line break was ASCII 13, to which \r maps. n would be ASCII 10. MPW had an option to swap the two, maybe that confused you.
2) The Icon\r file is still being used by OS X Finder even when you create new custom icons. .VolumeIcon.icns is only used at the root level of a partition. Don’t ask me why, but I just tried it (10.3).
Might be a good idea to report this as a bug in SVN so they can fix it.
Comments are closed.