Jump to content

Lost Vectorworks Files


Recommended Posts

Does anyone else have a problem with VW 12.5 files just dissappearing. Within our office we have a number of issues with files being created and saved on a server. The VW file can be see in its correct location but when you double click on it to open it, the file completely dissappears and has to be resored from the backup tape. This is OK if the file has been backed up overnight. If it happens within the same working day, hours of work can be lost.

Any hints, tips or suggestions would be welcomed.

Link to comment

I'm having similar issues. We are running Mac OS X Server, Mac OS X 10.4.x and VectorWorks 12/12.5 on client machines. We end up with 4k and (zero k) 0k corrupted files that cannot be recovered. I've been recovering successfully from backup, but it has happened enough now that I'm starting to get curious about what's happening. This has occurred pre12.5 but I've had 3 issues in the past week with 12.5 upgraded clients.

Link to comment

Dexie -

I'm investigating this a little further before I comment

David -

You shouldn't be having this problem with 12.5 that often. We've changed the file saving structure to include a number of extra checks before writing the file.

We are aware of some OS related file corruption issues that we are working with Apple on, but these should only occur rarely.

What version of OS 10 is the server running?

Do you frequently run disk utility to verify and repair disk permissions on the server?

Link to comment

Katie,

My most recent occurrance of a corrupted file happened on Friday of last week. It resulted in a 4k file. The client is on Mac OS X 10.4.7, VectorWorks 12.5 and the server which he was working from is Mac OS X Server 10.4.8.

Disk Utility/Repair permissions was last run on Wednesday after a server software update. Repair permissions is usually run when running software updates, but not frequently since it only repairs system file permissions.

-David

Link to comment

Update the client to 10.4.8 and see how it works out for you.

If the problem happens again, please try to keep track of the following information:

How was the file saved

How was the file closed

How was the file opened

How many characters make up the entire path, including the file name

Is there any possibility that someone else was opening the file when the file was already open

Link to comment
  • 2 weeks later...

Katie, a new issue just came up today. This is not the same user. Client is VW 12.5, OS X 10.4.7. Server is OS X Server 10.4.8. File was opened over the network for viewing and closed without saving. The result is a 4k corrupted file. The entire path and file name is fairly long. We have large projects, multiple users accessing files, many files nested deep within project folders. It's always possible that someone else may have tried to open the file. The main problem I see is that things have changed for the worse after I updated to 12.5. I saw this happen once pre12.5 and about 5 times now post 12.5. Thanks for your help as always.

Link to comment

We have successfully opened and worked in files across our network. The 4k files are probably the result of your backup software copying a file that is open. What would happen is our backup software would update the latest files while we worked on them. Since it could not do this, we were left with 4k files that overwrote the real files on the server. We quickly abandoned this and now work across the network on files with no issues...

Link to comment

Thanks for the tips guys. I've thought about other possibilities, however, our project teams have been at times as big as 8 architects all sharing and referencing the same files. It is a necessity to work from the server today. As for the backup, it is only run during non-work hours when files have been closed. Even then, the backup server does not have rights to restore or update back to the working directories on it's own. This new issue has only come up recently with the update to 12.5, never in the past have I had network file corruption issues like this.

Link to comment

I hadn't noticed before, but there are possibly several builds of VW 12.5. Like some of you, I had downloaded VW 12.5 update on day one and proceeded to use that updater to upgrade all of my machines. I ended up with build 60762. You can see the build number in About VW (or equivilent in Windows). I downloaded the update again yesterday and ran it on top of 12.5. It updated my 12.5 (build 60762) to 12.5 (build 61447). Only needed to update a few files including the core application. While there hasn't been enough time to test if this will solve my issue, it's another step I'm trying out.

Link to comment

By a process of trial and error we have discovered a problem which certainly affects MACs running V12.5 (possibly PCs as well).

If you try to save a file where the parent folder on our server (i.e the folder you are saving into) is more than 30 characters long ? then it is possible to get a file save error which results in the file being destroyed completely!

Link to comment

I to am seeing this much more frequently with VectorWorks 12.5 on Mac OS 10.4.8 and would love to have a resolution soon.

Our server and clients are running the latest updates (10.4.8). We repair permissions on server and clients after updates and every few days using ARD.

Katie, what are the OS related file corruption issues you are working on with Apple?

Link to comment
  • 5 weeks later...
If the problem happens again, please try to keep track of the following information:

How was the file saved

How was the file closed

How was the file opened

How many characters make up the entire path, including the file name

Is there any possibility that someone else was opening the file when the file was already open

Here's two more from another office.

Client / OS X Server both on 10.4.8 w/XServe G4

server access via AFP

Files were left open overnight. Next morning they were 4K. One was just sitting there, the other being used to generate a rendering. (Yes, I know over the network was not the fastest way to do this, he's been told.)

File paths are long. Say over 60 characters, maybe over 100.

We're suspicious of our backup. Twice a day at 1PM and 11PM Retrospect, on a 3rd machine, does a duplicate of the entire shared space to another machine. (We backup this duplicate to tape at night.)

VW Build 12.5.0(60761)

Retrospect v6.1.126

OS X Server 10.4.8 (8L127)

Any suggestions?

Link to comment
  • 3 weeks later...

I've run into the same basic problem, a file being deleted. In my opinion there is a SERIOUS BUG somewhere in VW. Here are the circumstances.

VWA12.5, build 61147. OSX 10.3.9. PowerPC. 512mb ram.

A 4mb file of design layers was reduced to a 4k shell. All data lost. I have a backup but did lose some work.

File data was lost in a VW crash. Version 12.5, even this long after 12 release, crashes here more than any other version in recent memory. Version 10 was stable for a few months at a time. 12 seems to go down every week or so. Still better than 3, which went south a couple times a day, but expectations have changed.

Immediately prior to the crash I had double clicked on a view port. I'm new to this feature so I was exploring. There was no way to exit the viewport. No button in the upper right corner or anyplace. I was stuck for a moment in the viewport and then, goodbye. Could not reopen the design file that the viewport linked to. The file containing the viewport seems ok.

The file construction I'm working with (someone else's) has the design layers in one file and sheet layers in a couple others. These started out at another office, which uses a server for their files. I found that I had to redirect the workgroup reference to the design file location on my computer. I seem to have been able to do this, and was able to get viewports to update. Now, interestingly, the sheets file shows the original design file info, not including the changes I made prior to losing the design file.

Hope someone is looking into this.

Regards,

Donald

Link to comment
  • 2 weeks later...

OK, our version of the same problem:

Server and clients are 10.4.8, clients running 12.5.

Retrospect is in the picture, but only backs up at night, whereas we suspect this is happening just as one closes out of a file, maybe only on quiting VW.

I reassign permissions on the server once a month or so, to correct user created folder privileges, but never permissions/disk check. I'll give that a try. Need to bump everyone, etc.

One of our projects with a dead file has a relatively short file path:

sparch docs(thats the server)/projects/0601 philastan/cad/Base plan.mcd

on the other, its:

sparch docs/projects/0504 fishman/0504 cad/VW/current/house 02.mcd

I can tighten up that second path, although there a million workgroup references that will need relinking. Sigh.

Any though as to whether 12.5.1 fixes any of this? With Microstation there was a way to define a default path start point, in my case above I would have it start at /projects which would save a step or two... Does VW have anything like this?

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...