For reasons which should be apparent, I did this before starting to play EMC Bond Mine 11 level 71:

$ cp ~/.rocksndiamonds/tapes/emc_bond_mine_11/07{0,1}.tape

I then played it back until the point where I had to diverge (much sooner than I'd expected) and solved the level from there.

After solving the level, I went to play it back (as I usually do) and was surprised to see that I died early; in fact, at exactly the same point as when I tried to play back the unmodified copy of the level 70 tape.

From behavior, it appears that the following is a true description of what happened:

1. Externally copy level 70's tape to the name for level 71's tape
2. Play (solve) level 71
3. Agree that the tape should be overwritten
4. [bug] RnD writes the data to the filename for level 70, not 71 -- apparently feeding the "%d" for level-number from the previously loaded tape data rather than the number of the level just played
5. At this point, 070.tape contains a solution to level 71, while 071.tape contains a solution to level 70!

I've had things like this happen before, but didn't catch the details well enough to report it.

Thinking back to previous instances, I think it in fact uses both the levelset name and level number from the prior saved data. So if you copy a single level from one levelset to another, copy the corresponding tape to the expected new place, replay that tape part-way, take manual control, change it, save it -- it overwrites tapes/$OriginalLevelSet/$OriginalLevelNumber.tape

(But I did not test the cross-levelset aspect this time and could be misremembering. The code surely knows :)

No matter where the file is physically stored, the binary data in the tape file contains an INFO block which is supposed to tell RnD what levelset and level number it's supposed to play, and copying the file obviously doesn't change the contents there. I'm not aware of any mechanism for playing back tapes other than using the default %d.tape file in either the user-saved tapes or the IST folder, so does the game still have any reason to honor that block at all? Perhaps we could bump the tape format to eliminate that block, preventing the game from getting confused by migrations like this.

Another alternative is to have the game automatically update and save the metadata in the INFO block any time it tries to play a tape that appears to disagree about what set or level it's in, possibly after prompting the user.

I think R'n'D should not use the information from the "INFO" chunk of the tape file if it is stored at a "standard" location (inside a normal tape or solution tape directory). This information is stored in level and tape files to make them "self-contained", e.g. to be able to throw a level or a tape file towards R'n'D and let it play it correctly (by using drag-and-drop, for example) in some future version of R'n'D.

In addition, the "INFO" chunk can also be used to identify a level or tape file using the Unix "file" command (which of course requires a "magic" file that was prepared in advance, like it was described in some other post I wrote years ago and which I could dig out again if anybody should be interested).

I'd handle the /etc/magic issue by putting a "rocksndiamonds.magic" file into the source tree; and probably a `make magic` target in the Makefile (if there's anything lie a unified coherent way to do that on all applicable systems -- seems dubious).

If the Makefile target isn't possible, perhaps just comments in the file saying "append this to your /etc/magic and/or read your file(1) man page to learn how to do it on your systems"...

Regarding the /etc/magic file: I found that that one identifies many of the level files, but fails on even more. Specifically it fails on Emerald Mine and the Classic Supaplex level bundle (/usr/share/games/rocksndiamonds/levels/Classic_Games/classic_supaplex/levels.dat)

I added these statements and almost half of the EM files become recognizable: