Continue to Site

Welcome to MCAD Central

Join our MCAD Central community forums, the largest resource for MCAD (Mechanical Computer-Aided Design) professionals, including files, forums, jobs, articles, calendar, and more.

Write access issues using XP

cagami

New member
Hello All,



I was wondering if anybody's ever encountered this type of error:



When a few of us upgraded to Windows XP professional, we started
getting chronic "Filename could not be saved; check disk space or write
access" errors when saving to a networked file server. The only
fool-proof workaround is to save to a local drive and then move the
files back later (and they may be "uncorrupted" after that).
Needless to say, the problem is not related to permissions or disk
space! The error is impossible to reproduce, and PTC is
stumped. It seems to happen every day, but we can't predict
when. The two common factors in each occurrence are 1) Seat has
Windows XP operating system, and 2) File is attempting to write to the
file server, which is a Powermac X-Raid system (perhaps an unorthodox
pairing, but I'm not knowledgeable with respect to IT). We have
been using this file server for years with earlier versions of windows,
and never encountered this problem.



I can't believe that we are the only company in the Pro/E universe to have this problem!



Thanks in advance for any help!



Chris
 
Do you have any spaces in the path/name or CAPS? There are still some instances where Pro/E does not like these owing to it's history of being written for Unix. Unix is case sensitive and does not accept spaces. Supposedly, PTC has fixed this, but I just ran into a problem where my trail files were trying to be sent to c:\TEMP but it would not work till I changed it to c:\tmp (note: the lower case is what made it work, and I did have it set correctly in my config.pro)

Hope this helps.

Rob Reifsnyder
Applied Mechanical Technologies, Inc.
 
Is your server running close to the limit of client licenses? I had this same problem on my system - the solution was to reduce the idle disconnect timeoutperiod for each client to zero. That way, inactive users don't tie up licenses. There are more details at microsoft.com.
 
I had this problem when my path was really long, like 5 or 6 subdirectories deepon my disk with each directory being a long name.





Wayne
 
Thanks for all of the suggestions, guys!



Rob and Wayne - I don't think it has anything to do with pathnames,
because Windows 2000 seats use the same directories and don't have this
problem. Plus, if this were the case, you would think that the
problem would occur every time you write to such a directory - however,
we only get the problem sometimes. That's the aggravating thing - we can't predict or reproduce the problem.



It's also not related to the working directory situation mentioned by
Brian, because I get the problem when the "file_open_default_folder" is
set to "working directory", while other users have theirs set on
"default" and get it anyway.



John - I need to look into your point. We definitely max out our
licenses, but I would think that this problem would affect ALL save
processes, and not just ones that involve a networked file server (we
can save OK to local directories).



Thanks again!!!
 
Look under Administrative Tools/Event Viewer to see if your NIC is
temporarily losing connectivity. I have found XP a real b*tch for doing
this. What is even worse, if it loses the connection often enough it
will disable your NIC for you. M$ sucks





DB
 
The reason it happened so sporadically at our company was because each active user locks a network license for a short period of time. Every time you log in or save files to the server, you renew the license. Our system is licensed for 5 users, so only 5 at a time can have current licenses. If you are not actively using it, it becomes a passive lock, which can be dumped by another user actively trying to restore his license. If you have six users saving files at the same time, one of them gets your error message. Since each activation lasts for (by default) 15 minutes, we ran into problems.


The solution for us was to reduce the idle disconnect timeoutperiod for each client to zero, which is done with the server management tools on the server itself. That way, we get a much faster release of the locked licenses.
 
Unfortunately, I don't think ours has anything to do with
licensing. We have no problem saving to local drives when we
encounter the problem - not to mention that ONLY XP has the
problem. We only saw this problem for the very first time when
three of us (out of six) upgraded from Windows 2000.



Plus, sometimes the problem goes away after we purge...but not
always. This is also curious, because we have tons and tons of
file server space, so it really isn't about capacity.
 
Also, about DB's comment:



It seems to be "file-specific" in the sense that some part files remain
"saveable" even after we encounter the problem during a save process on
an assembly. In other words, when we get the problem during an
assembly save, we can still go back to the individual component part
files and save them.



Weird.
 

Sponsor

Articles From 3DCAD World

Back
Top