But like I said, V9T9 is deprecated - this means I literally never test it, and I only ever intended it for reading. Even if Classic99 created the file, it's not hard for a bug to have crept in. Recommending TIFILES format keeps you on the tested side of things.
It's probably helpful to cover what a DSRLNK does too..
A DSRLNK starts with a pointer to a PAB, which is a structure in VDP RAM that tells the DSR what the operation is (OPEN, READ, etc), what type of file is expected (DISPLAY, VARIABLE, FIXED, etc), what part of the file we're interested in (where applicable), and what the filename is. DSRLNK only cares about that filename part.
Now the filename is more properly a fully-qualified path, containing the device name, options, and the filename. Since options and the filename are DSR-specific, DSRLNK again only cares about the device name part. So it first identifies the name of the device you're after.
Next, it turns on all the DSR ROM cards, one at a time, and looks for a match for that name. (The better DSRLNKs also check GROMs). When a match is found, DSRLNK simply branches to the address specified for that name. (The DSR then again parses the PAB from scratch to work out what to do). One at a time is important because it is possible in the hardware to turn on two cards at the same time, but if you then try to read DSR space both cards will attempt to respond. Depending on how the cards are made, that can be bad. Crossing the streams.
Unfortunately, the way that the disk DSR was written, it assumes that the DSRLNK has done things in a particular way, and therefore that certain data is in specific memory locations, that a specific workspace is loaded, etc. So the DSRLNK has to have done all that -- but in the end its only job is to hand off to the correct DSR ROM routine.
In Classic99's DSR, the branch to the DSR ROM is what triggers the disk emulation to take place, so when you see in the debug that Classic99 has begun to handle a disk request, this means that your DSRLNK is done (except for turning the card back off when it returns). I can't think of anything you can put into a DSRLNK that would corrupt a file in that scenario... the structures that Classic99 are complaining about are at the sector level, rather than the record level.
It's also worth noting that a lot of that changes when you use the type 3 hack. Classic99 NO LONGER reads the file, it's only responsible for sector access to the disk image (nothing higher level). Most of the setup checks still take place, but when it reports "Handling %s via TICC DSR", all that means is its finished its internal housekeeping and handed off to the TI DSR, the rest of the access happens there. But this means you won't see the 'corrupt file' messages and the like, because Classic99 has no idea what that DSR is trying to do.