DP7.2 Project File Resource Offsets Always Damaged [SOLVED]

[nyesonic]

Hi Monkey Man

yes - report it please.

the more techlinks they get on this subject the more obvious it will be that (if) there is a problem at their end not just one machine playing up and the sooner they will get it sorted.

glad its not just me anyway

N

[monkey man]

Likewise, N.

I've received a reply but when I try to see the tech link, this is all I can get:

Site Error

An error was encountered while publishing this resource.

_mysql_exceptions.InterfaceError

Sorry, a site error occurred.
Traceback (innermost last):

Module ZPublisher.Publish, line 175, in publish_module_standard
Module Products.PlacelessTranslationService.PatchStringIO, line 51, in new_publish
Module ZPublisher.Publish, line 143, in publish
Module Zope.App.startup, line 227, in abort
Module ZODB.Transaction, line 139, in abort
Module Shared.DC.ZRDB.TM, line 63, in abort
Module Products.ZMySQLDA.db, line 328, in _abort
InterfaceError: (0, '')
Troubleshooting Suggestions

The URL may be incorrect.
The parameters passed to this resource may be incorrect.
A resource that this resource relies on may be encountering an error.
For more detailed information about the error, please refer to error log.

If the error persists please contact the site maintainer. Thank you for your patience.

Well, I'm not physically or mentally up to chasing this down right now as I'm trying to deal with my vacuum cleaner, fish light housing, video recorder, master keyboard, Supernova and answering machine all dying within a week of each other, so I'll try again tomorrow.

[monkey man]

O... K... it's worked now. Here's the exchange so far:

MOTU:
If the resource fork's are damaged then it will not be possible to reopen these files.

Monkey:
There are now 3 users experiencing this that I know of, Mr. X. Disk Warrior and an anti-virus app have thus far been the sources of alerts for we users.

Do you see any damage in the test file I sent?

How about "Get Info"? Do you see the DP version number?

If there's no version number, how can it be that the file is undamaged/no different from all my other (non-DP7.2x saved) files?

Of course I'd already specified the problem in full, including the "Get Info" symptom. Uugghh...

[monkey man]

Like sands through the hourglass... (or is that urine through a carpet?), the saga continues:

MOTU:
I have been unable to open this file.
Once the resource fork is damaged there is no way to recover that file.

Monkey:
Thank you, Mr. X.

I'd hoped the file could be examined and the glitch subsequently tracked down. Reverting to 7.12 is hardly a solution, and as I've said, painstaking efforts to clean install 7.2x on fresh, non-3rd party-infiltrated OS partitions have essentially exhausted my options; short of reprogramming DP somehow, nothing more can be humanly done.

As you're my last hope, may I please ask you to pass this on to someone involved in/with the programming side of things? This phenomenon could conceivably be a symptom of an as-yet-undiscovered issue - I've no way of knowing, but I do know that not addressing real issues as they arise invariably leads to greater consequences in life, love and... technology! LOL

Sorry about the long note. I sincerely hope I've made enough sense here.

Thank you again, Mr. X, for your time,
Nicky

[mess]

You need to provide them with before and after versions of the file. They can't do anything with just the corrupted file if the resource fork is damaged.

That said, there has to be something that you're doing that results in this and they NEED to know this. Without knowing HOW the file goes from A to B won't help them to actually fix the problem.

Where are the files stored? Is it on the boot volume or on a separate volume? Does it matter what drive the files are on? If it's a separate volume, how is it formatted?

Going through the techlink system can be a harrowing process, but you absolutely need to provide them with as much information on the problem as possible for them to bring it to QA/development and for them to be able to do anything with it other than throwing it back at tech for more back and forth to get more info.

Hell, it may even be worth the time and effort to offer to send MOTU the external drive you have that replicates the problem and including files that are still in an undamaged state.

[monkey man]

Hmm... thank you, M.

It doesn't matter where I save the dummy (or any) project, so the drive thing is out.

The fella implied that they can't examine it as it can't be loaded; I thought they'd be able to though as you seem to confirm. Of course, a file for comparison would greatly speed up the process of identifying anomalies, I'd have thought, so I see where you're coming from.

I'll offer something in the next exchange provided I can load that test file into 7.12.

Thank you again mate.

[mess]

Hmm... thank you, M.

It doesn't matter where I save the dummy (or any) project, so the drive thing is out.

The fella implied that they can't examine it as it can't be loaded; I thought they'd be able to though as you seem to confirm. Of course, a file for comparison would greatly speed up the process of identifying anomalies, I'd have thought, so I see where you're coming from.

I'll offer something in the next exchange provided I can load that test file into 7.12.

Thank you again mate.

Dev will look at it and tell the tech "the file's corrupt, what did they do to make it that way?" A before and after will pinpoint the anomaly and possibly allow them to fix what is wrong with that specific file. Knowing what was done between the file working and not working, along with the before and after files, will help point them down the codepath to fix it. Having a reliable in-house test case will greatly help them in fixing the issue.

Developers are unlikely to fix a problem if they can't make it happen.

[kassonica]

Hmm... thank you, M.

It doesn't matter where I save the dummy (or any) project, so the drive thing is out.

The fella implied that they can't examine it as it can't be loaded; I thought they'd be able to though as you seem to confirm. Of course, a file for comparison would greatly speed up the process of identifying anomalies, I'd have thought, so I see where you're coming from.

I'll offer something in the next exchange provided I can load that test file into 7.12.

Thank you again mate.

Maybe you should send it to MagicD, Nicky......

[monkey man]

The thought actually crossed my mind before the tech link option, Kass. This is in fact the first one I've ever created, the situation catalyzed by the absence of a solution here at this esteemed house of wisdom. We'll see. I don't want to bother him unnecessarily. With any luck, he'll magically appear, as is his way, where the need calls. He's responded to dog whistles in the past, hasn't he? Legendary bloke, the ol' Magic One.

[Some time later]
I've just loaded the supposedly-unreadable file into DP7.12 and the new saved file seems fine, as one would expect given my experimentation.

Trickling it to MOTU as I type...

[sinkd]

Hello all,

You can add me to list of those having this issue. I posted a tech link about this a week ago.

DS

[monkey man]

Ripper!

Way to go man.

We're bound to be "heard", methinks...

[nyesonic]

Hi Guys

thanks for gathering evidence on this - as you say they need as much info as possible to fix it.
At least you are getting a response. My original Techlink still says unread after a month and a second reminder (under the same link)

as for "before and after" the problem is there is no before - all I have to do is select new project and save and I've created a damaged resource.

contrary to the advice you've been given M (I suspect this is the same for you) it is possible to open these files. Its also possible to resave them at which point the error becomes "overlapping resources found" (I put all this in my original TechLink of course)

Since this first happened I have changed both the disk I was saving to and the disk I was running dp off with no change

the other odd thing is that if you load the corrupted project into 7.1 and save the errror disappears - all this leads me to wonder whether it isn't in fact a damaged resource at all but something that DiskWarrior interprets as a damaged resource

best
Nye

[bayswater]

this leads me to wonder whether it isn't in fact a damaged resource at all but something that DiskWarrior interprets as a damaged resource

We can only hope that is all it is. I stopped using DW a long time ago because of this. It kept reporting things that technically were file errors, but they were of no consequence.

[monkey man]

Makes sense, Baysey; that's pretty much Dave Polich's attitude on this. As I told him though, I've been badly burned by ignoring, at the advice of others, such file-check warnings. If damage is deemed irreparable, this only adds to my hesitance.

Nye, I haven't heard from MOTU since sending the uncorrupted, comparison file, so I'd like to think they're busy getting to the bottom of it. Hopefully our contributions are useful at the House of MOTU, eh?

Heck, let's pretend this'll be sorted by the next DP update. I've a good feelin' about this.

[monkey man]

DP7.22 has reportedly corrected the issue.

Thread title updated.