Damaged transactions that cannot be deleted

Dana Netherton

I have Quicken Deluxe for Windows (on Windows 10), version R41.19, Build 2.1.41.19.

After a file validation/repair yesterday (on 7/6/2022), I discovered this entry in the data log:

"The following transaction(s) involving transfers appear to be damaged.
You should delete them and recreate as appropriate.

Account Investment Savings: 6/29/2021 Vanguard Investment Savings 22,000.00"

Today, I found the transaction. It was a flawed duplicate of a genuine transfer transaction that was also in the account's register -- flawed, because it did not show any account as the source of the transfer.

I deleted it. Then I validated/repaired the file again.

The transaction was back. And the new data log continued to include the entry I just quoted.

I deleted it again. (This time, I "cut" the transaction.) Then I SUPER-validated/repaired the file.

The transaction was back. And the new data log continued to include the entry I just quoted.

I have discovered similar transactions in other accounts in this Quicken file: duplicate entries, showing the same dollar amounts but with no account or category information; duplicate entries that also "would not die." (But none of *those* transactions was reported in the data logs.) I have found duplicate entries with dates in April 2016 and April 2022, as well as the June 2021 entry I am describing here. However in this post I am focusing on this single 2021 transaction.

My principal gripe about this thing is the effect it has on account balances. Quicken thinks I have big cash balances in some of my investment accounts, because only the money from the genuine transfer was removed from "cash on hand" to purchase shares. My balance in at least one credit card account won't balance, because it has a duplicate of a payment transaction. And so forth.

Since it appears that I cannot delete (or cut) the duplicate transactions, I am inclined to "work around" this problem by adding a transaction for each duplicate that I find, with the same dollar amount but the opposite plus/minus sign. That, at least, should zero out the harm these transactions are doing to my account balances.

But if somebody has a roach-killer that might rid me of these troublesome duplicates altogether, I'm open to hearing about it.

Please note:

1. I tried to "report [this] problem" within Quicken. The report did not go through. I don't know why, and I'm not inclined to dive into troubleshooting *that* along with *this*.

2. I have read some other recent posts reporting similar problems. A helpful suggestion from Quicken Anja on one post showed me how to "Super Validate/Repair" my file. (Thank you!) Restoring from backups will probably not help me if Quicken started inserting these ghost transactions as long ago as 2016. The Copy/Template feature -- hmm. Shall I reinvent the electronic connections I have with maybe eighteen financial institutions, in order to (maybe) fix a glitch that has affected maybe five or six transactions in the last six years? (Weighs each choice in my hands) I think I'll stick with the file I've got now.

I do have "save as" versions of my data logs from those validations (none of the data logs has the phrase, "Damaged data block"); I do have screenshots of "before," and "during" and "after." I don't plan to burden folks with that stuff unless it might do somebody some good.

[Deleted User]

@Dana Netherton  have you tried deleting out the "genuine" transfer along with the "flawed" one and then do a validate?  If the validate is clean, then just enter the "genuine" transfer back into Quicken.

Rocket J Squirrel

Try deleting the transaction and immediately doing a File > Copy. That "should" leave behind deleted things.

Dana Netherton

> @Rocket J Squirrel said:
> Try deleting the transaction and immediately doing a File > Copy. That "should" leave behind deleted things.

¿Is this different from the process I referred to, when I said: ?
> The Copy/Template feature -- hmm. Shall I reinvent the electronic connections I have with maybe eighteen financial institutions, in order to (maybe) fix a glitch that has affected maybe five or six transactions in the last six years? (Weighs each choice in my hands) I think I'll stick with the file I've got now.

Dana Netherton

> @Damian said:
> @Dana Netherton  have you tried deleting out the "genuine" transfer along with the "flawed" one and then do a validate?  If the validate is clean, then just enter the "genuine" transfer back into Quicken.

Interesting. I'll try that, and get back to you.

Dana Netherton

> @Dana Netherton said:
> > @Damian said:
> > @Dana Netherton  have you tried deleting out the "genuine" transfer along with the "flawed" one and then do a validate?  If the validate is clean, then just enter the "genuine" transfer back into Quicken.
>
> Interesting. I'll try that, and get back to you.

Well. That was interesting.

Short version:

I went through the process twice.

First time: I deleted both transfers (yup, they're both gone), validated the file, and went back to the investment account. The flawed transfer transaction was back. Only the flawed transaction.

I tried to edit that transaction -- "edit," then enter the bank's account into the "transfer account" field -- but when I hit "Enter/Done" the transaction simply did not reflect the change. The "account" field was still empty. Hit "enter" on the transaction itself, in the register -- still no change. (No error message to report, because there wasn't any error message)

Then I tried to create the genuine transfer transaction again, in the investment account. When I hit "Enter/Done" here, Quicken asked me -- wait, isn't this the same thing as this other transaction that already exists? I hit "Cancel" and went over to my bank account. Yup, found the corresponding transfer transaction there. Clicked on "go to matching transfer" -- and *now* found the genuine transfer sitting in the investment account. An entry that had not been there, less than a minute before.

Huh.

I validated the file again. Then (once again) deleted both transfers, in the investment account. Went to the bank account -- yup, no transfer transaction there. Back to the investment account -- both of the old transactions, still gone.

So now I set out to create the genuine transfer transaction -- but this time, I created it in the bank account (not in the investment account). This time, that seemed to have worked. In the investment account, there's one genuine transfer from the bank and no ghostly duplicate transfer from The Phantom Zone (or wherever). Success! right?

After backing up this version of the file, I validated it. Closed the file, reopened it, fingers crossed. Started in the bank account. Found the transfer. "Go to matching transfer." Now in the investment account, scrolled up a little. Yup, the genuine transaction is there.

As well as the flawed duplicate Phantom Zone transfer transaction.

After I validated the file that I now had -- yet again -- here's what the DATA_LOG reported. ((For brevity, I'm going to cut some "info" entries that don't matter here.)

[Fri Jul 08 16:18:58 2022]

File: "C:\Users\Owner\Documents\Quicken\NETHERTON"

QDF:
Validating your data.
...
Quicken repaired damaged transaction index. No action required.
Quicken found an invalid transaction and removed it. "ACCT_156d5" 0/ 0/1900
Quicken repaired some transaction information. No action required.
"ACCT_156d5" 0/ 0/1900
Quicken found an invalid transaction and removed it. "ACCT_156d5" 0/ 0/1900
Quicken repaired some transaction information. No action required.
"ACCT_156d5" 0/ 0/1900

Summary:
Quicken repaired 1 accounts. No action required.


For the record, I have no idea what "ACCT_156d5" may refer to. I have never seen those alphanumerics in any Account List, in any Category List, in any Tag List or Security List. (I pulled out some recent backups and restored them, to see if something had been lurking around before I did all this stuff. Nope, still nothing.)

As far as I can tell, when Quicken "repaired" my transaction index and that one account, what it did was -- to resurrect that damaged transaction. That damaged, incapable-of-being-corrected transaction.

I've got screenshots and data log files, if anyone needs to see them. Again, I won't burden folks with them if they wouldn't matter.

Damian, that suggestion made sense and was worth trying. Ah well.

Rocket J Squirrel

Dana Netherton said:

> @Rocket J Squirrel said:
> Try deleting the transaction and immediately doing a File > Copy. That "should" leave behind deleted things.

¿Is this different from the process I referred to, when I said: ?
> The Copy/Template feature -- hmm. Shall I reinvent the electronic connections I have with maybe eighteen financial institutions, in order to (maybe) fix a glitch that has affected maybe five or six transactions in the last six years? (Weighs each choice in my hands) I think I'll stick with the file I've got now.

No, it's not different, but you said you didn't do it.

UKR

> "For the record, I have no idea what "ACCT_156d5" may refer to. "

That's a ghost from the past.
Quite a few years ago, accounts named ACCT_xxx, TEMP_xxx or TMP_xxx were used during transaction download to temporarily store downloaded transactions. (I don't know if they are still being used or if the programmers reinvented that wheel). If something happened during download processing, these accounts and their transactions could have been left behind. Normally that causes no problems, but Validate and Supervalidate were the only ways to ferret these hidden accounts out and make them both visible and deletable from the account list.

Dana Netherton

> @Rocket J Squirrel said:
> No, it's not different, but you said you didn't do it.

And I also said why I wasn't going to do it.

Dana Netherton

> @UKR said:
> > "For the record, I have no idea what "ACCT_156d5" may refer to. "That's a ghost from the past.
> Quite a few years ago, accounts named ACCT_xxx, TEMP_xxx or TMP_xxx were used during transaction download to temporarily store downloaded transactions. (I don't know if they are still being used or if the programmers reinvented that wheel). If something happened during download processing, these accounts and their transactions could have been left behind. Normally that causes no problems, but Validate and Supervalidate were the only ways to ferret these hidden accounts out and make them both visible and deletable from the account list.

Ah. Ah. Perhaps those accounts are now being used (sometimes, at least) as intermediate locations for transfers between the originating-account and the ultimate destination-account? Like a "parking lot" or an Accounts Receivable account? And when the transfers are complete, the temporary accounts are supposed to be deleted, quietly, behind the scenes -- along with the (temporary) transfer transactions that use them?

Hmm. Perhaps that may explain what is going on behind the curtain, here. Perhaps in my case this process is using temporary accounts named "ACT_156xxx."

Perhaps something is going glitchy in that process.

Perhaps that could explain why validation (and supervalidation) sometimes discovers shreds of such an account, resurrects it, and then deletes it.

Perhaps the now-flawed transaction was originally a temporary entry reflecting money being transferred between the temporary account and the ultimate-destination-account. But, with that transaction's originating account (the temporary account) now deleted, the transaction's "transfer account" (originating account) field is now empty. And, like the temporary account, this transaction is *also* getting resurrected by validation (and supervalidation). But, unlike the temporary account, this transaction is *not* getting deleted by validation (and supervalidation).

And perhaps it is somehow still wrapped-up in that temporary process, and is therefore not configured to allow a manual edit that would put a real account into that "transfer account" field.

Perhaps.

If so, 'twould seem that a substantive "fix" to the problem might not be trivial. And would certainly not be something available to the user (however much a "power user" they may be).

Hmm. Those "zeroing-out" manual dummy transactions are sounding more and more attractive, as a simple kludge that a user can create. Perhaps with a unique Tag that I would create and use -- so that I can find them quickly (and remove them), once the problem has been fixed.

Interesting. Thanks!

J_Mike

@Dana Netherton

Awhile back, I encountered a similar problem with damaged transaction and was unable to correct.

My solution was to create a new account and then move all nut the damaged transaction to the new account. Reentered thee damaged transaction and all went well. (Deleted old account.)

Dana Netherton

> @J_Mike said:
> @Dana Netherton
>
> Awhile back, I encountered a similar problem with damaged transaction and was unable to correct.
>
> My solution was to create a new account and then move all nut the damaged transaction to the new account. Reentered thee damaged transaction and all went well. (Deleted old account.)

Interesting. Did the account have electronic "connections" with a financial institution? Did you have to disconnect the old account, and then connect the new account to the institution?

J_Mike

Dana Netherton said:

> @J_Mike said:

Interesting. Did the account have electronic "connections" with a financial institution? Did you have to disconnect the old account, and then connect the new account to the institution?

In my case the account was an old, inactive account - no connections at the time. I noticed that the account started showing a cash balance when it should have been zero. Tracked the problem from there.

In your case, with an active account, I would first deactivate the existing account, Complete the move to a new account. Then activate the new account for download,

Dana Netherton

> @J_Mike said:
> In my case the account was an old, inactive account - no connections at the time. I noticed that the account started showing a cash balance when it should have been zero. Tracked the problem from there.
>
> In your case, with an active account, I would first deactivate the existing account, Complete the move to a new account. Then activate the new account for download,

I see. Each of the accounts affected in my file does have electronic connections with a financial institution (bank, credit card company, investment firm)). I'd have to think hard about replacing the accounts like this. Thanks for the suggestion. I'm undecided about it, at this point.

Sherlock

You do realize you may try the Copy/Template feature if just to determine if it helps to resolve the issue.  If it does, you may use a release prior to R34.13 to perform the earlier Copy functionality that does not disconnect the Online Services.

If you do go down this path, I suggest you use an earlier version of the subscription's installation program, perform the install disconnected from the internet, and apply an appropriate Mondo patch.  An earlier version of the subscription's installation program is available at: https://www.quicknperlwiz.com/install-for-quicken-2018---subscription.html  An appropriate Mondo patch may be downloaded from: https://www.quicken.com/support/patching-updates-windows or http://www.quicknperlwiz.com/quickenpatches.html

To prevent Quicken from applying an update without your approval, I suggest you set Windows UAC settings appropriately (choose default or always notify).


The fact that you're able to delete these transactions and they reappear some time later leads me to suspect the issue may be due to a corrupt cloud account.  To confirm the theory, disconnect the internet before you delete the transactions.  If the transaction do not reappear until you have enabled internet connectivity, the cloud account is likely the source of the issue.  If so, I suggest you disconnect the internet, delete the transactions, close the Quicken file, enable the internet, open a different Quicken file (File > New Quicken file...), and delete the cloud account associated with the original Quicken file: https://www.quicken.com/support/how-edit-or-delete-your-cloud-datasets-quicken-windows

markus1957

As @UKR stated, Quicken may still be using those hidden temp accounts as part of the downloaded transaction acceptance process.  The temp accounts normally get cleared out as part of a cleanup process that runs when Quicken is closed and all transactions are accepted. 

I'll offer 2 possible reasons for the issue you are seeing.

1. Running validate/repair before closing Quicken could resurrect damaged transactions from the temp account(s) that is still active in the file. Validate/Repair should be run when first opening Quicken, but definitely before downloading transactions to assure no temp accounts are active.

2. The damaged transactions may be corrupting the temp account(s) and preventing its deletion during the Quicken close process. Then running validate restores the damaged transaction. The temp account(s) needs to be deleted manually. This can be accomplished by creating a manual transfer from a spending account register to the temp account by entering the bracketed temp account name in the category field; in your case [ACCT_156d5].  Then after saving the transfer, right click it and use the "Go to matching transfer" function to open the register for the hidden account. Next using the Gear icon in the hidden account register, Edit Account details will open a window that contains an option to delete the account.

Another way to inspect hidden accounts in Quicken is to use Find/Replace from the Edit menu. Use the Find filter Cleared Status, Contains, Uncleared. In addition to normal uncleared transactions, you will see transactions from hidden accounts in Quicken. Clicking on the transaction date will take you to the account register. Be aware that there are a few permanent hidden accounts like the "Tax impact" account that should not be deleted (except under special circumstances where they are the problem and with special caution not to hose your file; in your case leave these accounts alone). Only delete accounts with names like "Acct_xxx". And only delete them in a freshly opened Quicken file.

Dana Netherton

Thank you, @Sherlock and @markus1957. There's a lot to think about here. I'll look into them.

Dana Netherton

> On July 10, @markus1957 said:
> As @UKR stated, Quicken may still be using those hidden temp accounts as part of the downloaded transaction acceptance process.  The temp accounts normally get cleared out as part of a cleanup process that runs when Quicken is closed and all transactions are accepted. 
>
> I'll offer 2 possible reasons for the issue you are seeing.
>
> 1. Running validate/repair before closing Quicken could resurrect damaged transactions from the temp account(s) that is still active in the file. Validate/Repair should be run when first opening Quicken, but definitely before downloading transactions to assure no temp accounts are active.
>
> 2. The damaged transactions may be corrupting the temp account(s) and preventing its deletion during the Quicken close process. Then running validate restores the damaged transaction. The temp account(s) needs to be deleted manually. This can be accomplished by creating a manual transfer from a spending account register to the temp account by entering the bracketed temp account name in the category field; in your case [ACCT_156d5].  Then after saving the transfer, right click it and use the "Go to matching transfer" function to open the register for the hidden account. Next using the Gear icon in the hidden account register, Edit Account details will open a window that contains an option to delete the account.
>
> Another way to inspect hidden accounts in Quicken is to use Find/Replace from the Edit menu. Use the Find filter Cleared Status, Contains, Uncleared. In addition to normal uncleared transactions, you will see transactions from hidden accounts in Quicken. Clicking on the transaction date will take you to the account register. Be aware that there are a few permanent hidden accounts like the "Tax impact" account that should not be deleted (except under special circumstances where they are the problem and with special caution not to hose your file; in your case leave these accounts alone). Only delete accounts with names like "Acct_xxx". And only delete them in a freshly opened Quicken file.

Thank you for your suggestions. Here's what happened.

I should begin by saying that I haven't opened Quicken for about a week -- to let the dust settle, and to prevent adding more complexity to an already complex situation.

So. First, following your "another way" suggestion above, I tried to use Find/Replace to look for hidden accounts. Using the filter settings you suggested, I did find the "tax impact" accounts you cautioned me about. But I found no ACCT_xxx accts.

Second, following your "#2" suggestion above, I opened the register of one of my idle credit cards and created a transfer transaction between that account and an "ACC_xxx" account named in my data logs. Well, actually I did that with several "ACC_xxx" accounts ...

Looking through my data logs, I discovered that I have had a series of such accounts in the course of this odyssey:
- ACCT_156cf
- ACCT_156d2
- ACCT_156d3
- ACCT_156d4
- ACCT_156d5

I created a transfer transaction for each of them.

The first four times (the first four accounts), after I entered the account name ("[ACCT_156xx]"), Quicken objected: "Account does not exist. Create a new account and then return to this activity."

Since all these had been generated during a series of validation/repair operations, I suppose the first four had already been deleted by the operations.

When I entered the final account name, for the "d5" temporary account, I was able to tab to the next field without complaints from Quicken.

I then got into the "Edit" menu to find the "go to matching transfer" operation. That operation was grayed-out. Couldn't do it. I clicked on "Save" (the transaction), and tried again. Still grayed-out.

I checked the Account List, JIC (just in case). Nope, not on the list, even with "hidden accounts" check-marked.

I deleted the transaction.

After this, I turned to @Sherlock 's suggestion (next post). That was an attempt to delete bogus transactions and repair/validate -- while not connected to the Internet. I'll say more about that in a moment.

What matters here is that, after going through all that and before coming back to this forum, I tried once more to create that transfer transaction to the temporary ACCT_xxx account. I got the same complaint ("Account does not exist") that I had gotten for the previous four accounts. So yes it looks like the validations/repairs did delete the temporary accounts.

Thank you for the suggestions.

Dana Netherton

> On July 10, @Sherlock said:
> You do realize you may try the Copy/Template feature if just to determine if it helps to resolve the issue.  If it does, you may use a release prior to R34.13 to perform the earlier Copy functionality that does not disconnect the Online Services.
>
> ...
>
> The fact that you're able to delete these transactions and they reappear some time later leads me to suspect the issue may be due to a corrupt cloud account.  To confirm the theory, disconnect the internet before you delete the transactions.  If the transaction do not reappear until you have enabled internet connectivity, the cloud account is likely the source of the issue.  If so, I suggest you disconnect the internet, delete the transactions, close the Quicken file, enable the internet, open a different Quicken file (File > New Quicken file...), and delete the cloud account associated with the original Quicken file: https://www.quicken.com/support/how-edit-or-delete-your-cloud-datasets-quicken-windows

Thank you. I may experiment with the Copy/Template feature, we'll see. In the meantime, I tried your suggestion about a possibly corrupt cloud account.

Which transaction should I delete? In all, I have identified problems with transfers from my banking account to two investment accounts and two credit card accounts, on dates ranging from 2018 to April 2022.

In a previous set of operations (see the account I just posted to @markus1957 ), I found that the data logs I have generated during these experiments have named five different temporary accounts, along the way. (The names are in that post.) I also found that only one of them still seemed to be lurking in my data file: ACCT_156d5. So I chose the transfer that seemed to be connected with this account. The receiving (investment) account had one genuine transfer and two identical uncategorized "transfer" transactions.

I disconnected my laptop from our WiFi -- from the internet. I deleted all three transactions: the genuine one, and the two "ghost" transactions. Checked the bank account -- yes, that register no longer had the transfer on its end, either. And I closed Quicken.

Then I opened Quicken, and validated/repaired the file (still disconnected from the Internet).

The bank account still showed no transfer. The investment showed ... one "ghost" transaction: an uncategorized deposit into the investment account, with no origin given for the deposit.

Relevent bits from data log:

[Sat Jul 16 17:09:40 2022]

File: "C:\Users\Owner\Documents\Quicken\NETHERTON"

QDF:
Validating your data.
Repaired your data file by removing a damaged category. Please check your category list for missing categories by going to Tools>Category List.
...
Quicken repaired some transaction information. No action required.
"Investment Savings" 6/29/2021 "Vanguard Investment Savings" "Sending surplus to Vanguard liquid savings"
Quicken repaired some transaction information. No action required.
"First Bank - CA, FL, IL, MO" 4/ 4/2022 "Automatic Payment - Thank You"

I was intrigued to see that it said nothing about any temporary accounts -- nothing about ACCT_156d5, or any other account.

I don't know what the "damaged category" was. I looked in my Category List, but didn't notice anything missing. Then again, it's a long list to eyeball ...

The "repaired ... transaction information" for 6/29/2021 seems to be the insertion of that ghost transaction into my Vanguard account.

And when I checked my bank account for any "repaired ... transaction information" for April 2022 ... I found *four* payments to a credit card: one genuine, three duplicates. Oddly, The credit card register shows two payments, not four.

Back in my bank account's register, I clicked on "go to matching transfer" for each transaction. Two sent me to the credit card register. The other two complained: "The transfer transaction is to an account that no longer exists in Quicken." Hmm. Perhaps the validation/repair did delete that account ... without deleting the transactions connected to it.

All, while disconnected from the Internet.

I have reconnected to the Internet, so I could post this report.

I do thank you for the suggestion. Though the result was frustrating, that's hardly your fault. And I'm saying this to everyone in this thread who has offered ideas. I thank you all for your thoughts.

Dana Netherton

P.S.: Those two transactions that balked at "go to matching transfer" -- each of them had the correct name of the correct credit card account (correctly within square brackets) in their "Category" fields. To all visual appearances, they were correctly formatted as Transfer transactions to that credit card account. It was only Quicken who could "know" that the transfers' destinations was to a now-deleted account.

This does sound like the sort of process that @UKR and others have described for transfer operations: using hidden temporary accounts in the course of setting-up the transfers, like black-clothed stage-hands, and intending to delete them when the process is complete.

I hope these things aren't going to get resurrected every time I do a validate/repair. To have to clean up after that operation, every time I run it -- not a pleasant thought.

Dana Netherton

As a follow-up to my last -- I have entered one dummy "offset" transaction for each income/expense/transfer transaction that duplicates a legit transaction. If the bogus/damaged transaction is an income/deposit/transfer-in transaction, I've entered a dummy expense/withdrawal/transfer-out transaction. And vice versa.

I have also created a separate Tag for these transactions. I call it, "Offset ghost transactions." I'm using it for all offset transactions in my "banking" accounts: checking, credit cards. Alas, it looks like transactions in "Investing" accounts don't have a field for "Tags," ah well.

In each case, I've been able to identify the "genuine" transaction in a given account. I have noted that, in its memo field. Where it's a transfer transaction, I have gone "to matching transfer" in the other account's register, and have entered a note there that that is the "genuine" transaction over there.

Most of the bogus/damaged transactions have an empty "category" or "account" field, and in most of those cases I have left that field empty in my corresponding dummy transactions.

I could not leave that field empty when I created "Cash transferred out of account" transactions in some of my investment accounts (to offset bogus "Cash transferred into account"/"XIn"/transfer transactions in those investment accounts), so I created an account I called "Dumping Ground."

(That field is empty in the bogus transactions, but Quicken balks and demands an entry when I create an offset transaction manually.) (Quicken also refuses to let me enter an account into the empty field in those bogus transactions: sometimes I can enter the name of an account, but when I try to leave the transaction, well -- Quicken invites me to "save" it; but when I click on "Save," nothing happens. Go figure.)

I have set this new account's Display Options to "Keep this account separate" and "Hide account name in account bar and account list." Of course I'm not hiding it in transaction entry lists -- I may need it again, if I have to create more of these dummy transactions.

(And, of course, after doing all that I have backed-up my file.)

Now, at last, my checking account's balance in Quicken is in the same vicinity as its balance in my bank's web site and monthly statements. My credit card account balances in Quicken fit their statements. And all of my investment accounts finally have zero cash balances.

Which was the bottom-line, for me.

What remains to be seen is whether I will have to go through this again -- create additional dummy/offset transactions for those (probably damaged) bogus transactions. Will each validation/repair operation on my Quicken file create more copies of these "bogus" transactions? I'm not eager to run more experiments on that. Or to run file validations lightly.

Well, if I do *need* to run a validation/repair, I'll keep this in mind as something to check afterward.

Again, thanks to everyone who has offered suggestions. It seems clear that the underlying cause of these bogus transactions lies somewhere inside Quicken's code -- inside its current design.

Which means, there's precious little we users can do to *solve* this thing. We can only apply kludges and band-aids (such as these) until it does get fixed.

And of course there's no telling when the thing might get fixed. If ever. Ah well.