Jump to content

12.5.1 mystery bomb


Recommended Posts

Since upgrading to 12.5.1, I've started getting "failure attempt to open file" error messages, after which, VW bombs. I have all my files on a server, and the bombing file has workgroup references, also in the same server and same folder. Any clue as to what is going on?

The referenced files are all updating correctly when the document opens, and I can manually update the referenced files as well. The bombs happen seemingly randomly, but frequently, typically every 5 minutes or so when I am using the file.

Servers and clients are running latest versions of OSX. Permissions are all repaired. No other apps running. No one else has the files open.

Any thoughts, apart from downgrading back to 12.5?

Link to comment

Keep in mind that OSX is extreeeeemely sensitive to the 'recursive' load order

of the application parts. Security requires the declaration of FilePaths and the management of all the application specific OS recursives.

One part missing or outta place and OSX simply stops the loading process.

When apps exhibit the behavior you describe it's usually possible to fix it using various techniques

beginning with the preference directories and then the FilePaths.

Check the Console Log for clues ; )

Link to comment

Partially. We are in the process of addressing this and one other issue immediately. A new updater for 12.5.1 will be posted by the end of next week, hopefully sooner. The new update will fix this problem.

The best thing to do right now is to roll back to 12.5.0.

Link to comment
  • Vectorworks, Inc Employee

There is a known problem with the backup folder option of the autosave feature in 12.5.1 on the Mac. When a backup folder does not exist, VectorWorks succeeds in creating it, but that initial backup save will fail and any attempt to close or save the file after that will result in a crash. Future autosaves for files in that folder will succeed because the Backup folder was successfully created.

As Katie mentioned, we're working on this problem and hope to have a patch posted soon. You can roll back to 12.5, or turn off the backup folder option of autosave and just autosave "in-place".

Mark Farnan

Core Technologies Manager

Nemetschek NA

Link to comment

All,

just thought you might like to know that I also got a ?failure on attempt to open file? error with the backup options off, and just trying to manually save an existing file (not save as) using version 12.5.1 on a Mac. VW did give me the chance of saving to a separate location after informing me the original file was now corrupt. I was unable to save the file to the server (a mac) - giving "failure on attempt to open file" and "disk I/O" errors before finally allowing me to save to my desktop and then bombing.

Double clicking on the desktop file resulted in another error, making me very nervous, until I managed to open the file through VW's open command.

I'm reporting this as I suspect the is not limited to the autosave feature - it's just more obvious with autosave as it executes every 15 minutes - manual saves are generally less frequent.

I'm getting version 12.5.1 off my machine right now, its dangerous. Good to see it's been taken off the download site.

It's a shame this bug wasn't picked up in beta testing. frown.gif

Link to comment

Thanks for letting us know Laurence, I'll be on the lookout for it.

While I am happy that NNA monitors and contributes to this message board, I have to be critical of NNA for this release. Not so much for the bugs, they can happen even with the best testing, but for the horrible error message. Good error messages are concise, accurate and diagnostic. This one in next to useless, and might just as well say "File open error" as my 1988 Mac Plus used to.

If this is the level of error reporting that NNA deems suitable, why not release your software engineers from the burden of error messages altogether, and have them spend more time on debugging their code. Back in the days when I used to write code, each major routine had to set a error message variable that was little more than an ID tag of the offending routine, which was provided along with every error message. Even better, why not give the file & path name, so that the end user might have a chance of discovering what the problem is. Had the error message said, "Cannot open '.../back-up/plan 12.mcd' (er:12345)." the offending problem would have been more obvious (if indeed that is the problem.)

(wander off topic)

I know that it is easy to criticize and hard to do, but NNA has an almost great product, and I keep wanting them to clean up the interface inconsistencies so that I can look forward to using the software, or at least have it disappear into the back-ground and let me get on with my design. As a former software engineer and a current architect, I well understand the difference between software that is designed by engineers and software designed by designers. If anyone at NNA would like a list of interface inconsistencies, I'd be happy to supply it. The 12.5 release was a huge improvement over 11, and I hope the next release is better again.

(/wander off topic)

I hope we get a fix soon.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...