Topic: Open Drawing Becoming Write Protected?

[BlackBox]

I've started having issues where the active document becomes read-only / write protected... While already open in my current session (you can actually see the lock symbol added to Drawing tab)... Completely killing productivity today.

I've read through this:

http://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/Error-Cannot-save-the-drawing-path-filename-dwg.html

... And verified that it's not NTFS/Share permissions, or Antivirus (I've both added file extensions to preclude, and it is currently disabled), and first saving local then saving to network works fine.

We installed a brand new Gigabit switch, at the same time as our new Server +/- 1.5 years ago, and there's been no infrastructure changes recently... Despite that, network lag is seemingly the only logical cause.


My workstation has worked fine since the network upgrades, but I did just have an MOBO issue - Dell took me through the BIOS to verify some settings, and we found that it was configured for 32-bit environment, despite shipping with Win8.1x64 + 32 GB RAM, etc. Grrr

It ended up being a MOBO issue nonetheless; Dell sent a replacement, I swapped it out, and modified BIOS for 64-Bit environment, switching from 64 PCI Buses to 256, etc. and my workstation performs better than ever now.

Current specs: Win10x64, Hex-Core Xeon E5-1650, stock Dell SSD (OS, Non-RAID), 32 GB RAM, 3 GB NVIDIA Quadro K4000, Gigabit NIC


Is it possible that my workstation is simply ready to overwrite the source .DWG file before the rights have been removed following the .BAK, .TMP, etc. file creation? I'm listed as the drawing owner in .DWL* files.

Anyone else know how to diagnose / correct?

[Edit] - I've been running this setup, working on the same project drawings for more than a week now, without issue. This undesired behavior just started today.

[ChrisCarlson]

Are you running A360? Try logging out, we had a similar issue where I think A360 was parsing or uploading DWG files and taking priority.

[BlackBox]

Are you running A360? Try logging out, we had a similar issue where I think A360 was parsing or uploading DWG files and taking priority.

Thanks for the prompt reply!

Following the MOBO replacement, I have a clean install of both Win10x64 + IDSP... I wondered the same, and had to log in to verify that both DWG + Settings were disabled, and then manually logged out... Although I did just notice that the service / process was still running (from when I logged in earlier - kill!).

I've also disabled A360 in Task Manager, so its not started at login.

Cheers

[cadtag]

DropBox running?  That's been reported as a cause -- fixed recently withe new dropbox client

[BlackBox]

DropBox running?  That's been reported as a cause -- fixed recently withe new dropbox client

Not even installed - to not duplicate files locally (that are already on the server), I've just been using the browser to upload, etc.

Although - I 'spose I could try killing Google Drive, since you mention DropBox, and see if that doesn't make a difference.

Cheers

[ribarm]

See attachment PNG...

OPTIONS ?

[Bryco]

Have the same problem here, those .dwl diles are hard to kill, sometimes restarting twice still doesn't kill them. When you can delete them, bizz as usual

[cadtag]

Remember that the DWL files are no longer used for file locking.  Locking is strictly a function of the workstation/server OS.  We're not exactly running R14 and WfW 3.1 anymore.

These days, the DWL files are only accessed by the WHOHAS command.

[BlackBox]

See attachment PNG...

OPTIONS ?

Same settings here (mostly), with slightly lower incremental value, given that I work with Civil 3D.

[BlackBox]

Remember that the DWL files are no longer used for file locking.  Locking is strictly a function of the workstation/server OS.  We're not exactly running R14 and WfW 3.1 anymore.

These days, the DWL files are only accessed by the WHOHAS command.

I actually didn't remember that, but still have no explanation for the issue - perhaps what you describe can lend credibility to my workstation otherwise performing substantially faster being the issue - when it was configured for 64 PCI Buses (in lieu of the 256 now), I didn't have near the performance, but drawing write/save was never an issue.

Any suggestions for diagnosing which applications are consuming which internal bandwidth (to try and verify), and/or how to set some limits (and give AutoCAD apps the lion's share)?

[Bryco]

2 days ago I had the problem until I could delete the dwl files, so that sugguests a lock to me, or is the workstation locking these too.  Acad 2016 here.

[BlackBox]

Everything seemed to be working fine yesterday afternoon (and into the wee hours of the morning, remotely!), after disabling Google Drive, and Trend... Re-enabled Trend, and no change (so far as I could tell).

Restarted my workstation, and on first save it happened again (my active document become write protected while open in my session, at save)... Went to look in the tray, and sure enough Google Drive was enabled at login... Disabled it again (leaving Trend active), and save activity seems to have normality restored.

It's still early in the day, but this seems like the best cause I've been able to determine so far.

[ChrisCarlson]

Almost sounds like AutoCAD sees the file as read-only (open) and changes the status but never rechecks once it is set to read-only to verify it indeed still is.

[cadtag]

ISAVEPERCENT should normally be set to zero.  That's also a legacy behavior from the bad old days of DOS, and serves no valid purpose anymore.

[jonesy]

We have had issues with this, ours usually seems to correspond with a loss/interruption of network connection... Although its probably nothing to do with that in reality  

[MP]

ISAVEPERCENT <snip> serves no valid purpose anymore.

Disagree. If you desire flaky, unreliable behaviour (especially if your project is network based) you can simply set ISAVEPERCENT to a non zero value and poof, boredom be cast away. 

[dgorsman]

Hmmm.  Value not set to 0 for some time, no "flaky" behavior present....

[BlackBox]

Given the reference to Dropbox, I did some reading on this, and do not feel it is related.

While I use Google Drive, I do not use it for any storage locations as those reporting issues with Dropbox do - I mostly use Drive to sync documentation, my .NET source code, CAD-related support/settings, etc. between work and home (in the event my terminal server is unavailable for sown reason). Nothing in my CAD setup is loaded from Drive - these are just backups.

That said, there is a literal difference in CAD behavior when Drive's service(s) are running, and when they're not - I'm at a loss on any correlation, besides the gigabit network, which has never been an issue before.

[ChrisCarlson]

Maybe Drive is indexing non-defined directories?

[BlackBox]

Not sure... Earlier this week, and yesterday (as I was attempting to make some last minute changes to a submittal per engineer Grrr), it was happening again.

Earlier in the week, I noticed the network was lagging, and saw there was a pending reboot on the file server. Restarted it, and all was well.

Yesterday, it started happening again, and I suspected the network this time but for users streaming music... As soon as most of them went home, the issue was gone... Thinking of throttling their bandwidth. 

No Drive, or Dropbox services have been running this entire time.

[cadtag]

... users streaming music... As soon as most of them went home, the issue was gone... Thinking of throttling their bandwidth. 
..

Personally, i'd block the sites they are streaming from, or b**chslap them.  No good reason for the company to pay for staff's daily entertainment (I'd rather they paid my salary and bonuses).  Tell 'em to load up their MP3 files on their personal ipods, or go out and buy a radio.

And yes, I've done the slapping around here before. 

[BlackBox]

Regardless of network traffic, I've found that the issue still happens on occasion - the issue specifically being traced to the .BAK file, as if/when this happens, and I even first save to local disk before attempting to re-save to network and am prompted that the file is in use by another session, I can manually delete the applicable .BAK file via Explorer, and the attempt to save back to network is successful.

At this point, I'm not even sure what to do with that.

I 'spose my next 'test' will be to disable .BAK altogether, and rely on automatic saves for the time being. Grrr

[cadtag]

Maybe try using MOVEBAK to set your .bak file location to the local machine Temp folder?

Any difference in this happening between Win 7, 8, 8,1, or 10 client OS?

And, although I'm sure it is,  verify that all updates have been applied to the server?

[BlackBox]

Okay, so I moved all of the .BAK files to the local temp folder used for automatic saves, and attempted to save my current drawing as the next, which already exists in .DWG and .BAK (I did use Tim's XREF Manager to modify the references early in this session... hrmmm? )... Point being, aside from that, I've added the next drawing (about to be overwritten) to SSM, and that's it.

The next drawing is not open in my, or anyone else's sessions at all....

Code: [Select]

Command: MOVEBAK
New value for MOVEBAK, or . for none <>: C:\CAD\Support\2015\temp
Command:
Command:
MOVEBAK
New value for MOVEBAK, or . for none <C:\CAD\Support\2015\temp>: *Cancel*
Command:
Command: SAVEAS
Deleting registered application "AECGUIBASE"
1 registry application deleted.

Updating Indexes for block *Model_Space
Done.
Updating Indexes for block *Model_Space
Done.
You have C:\CAD\Support\2015\temp\<FileName>.bak open. This file must be saved to complete the addition of page setup overrides for the sheet set.
Command:


[BlackBox]

I've continued doing the SAVEAS, and it does seem to be working properly (in the next two instances, that is).

I am a bit confused as to why the "SAV*.TMP" file is being saved to network first (DWGPREFIX?), rather than local to Profile's ..\Temp\, and then moved to network, but still... So far so good it seems... And for that, I thank you. :beer:

Cheers


[Edit] - Spoke too soon, already happening again; the active document becoming write protected whilst open in my own session. Grrr

[ronjonp]

I think you already tried this, but I've seen strange behavior with files in the past & it was the antivirus locking them.

[BlackBox]

I think you already tried this, but I've seen strange behavior with files in the past & it was the antivirus locking them.

I'll double check Trend's 'allowed program' settings; I've never added any over the past +/- 2 years, with exception of QuickBooks, and had no issues. I have installed all SPs, etc. since first installing IDSP 2015 (the version I'm currently using for this project), but still.

Have you experienced anything like this in Win10?


Neglected to answer CT's other questions above -

This workstation is a clean install of Win10x64 Enterprise + IDSP 2015/2016 following MOBO replacement.

All servers (physical/virtual) are Server 2012 R2, and have a weekly bare metal backup, preceding Windows Update installs + restart the following day (scheduled).


Cheers

[ronjonp]

*KNOCK ON WOOD*    My network has been running smoothly for quite a while now. No issues with Win 10 to date.

[BlackBox]

I'm thinking a combination of Trend (mostly), and my workstation being modified for 64-Bit performance (previously set for 32-Bit unbeknownst to me).

I say that, as I previously had zero issues at all (besides the lack of performance, that is Haha), only following the BIOS changes to my workstation did issues crop up, and while I had previously disabled Trend on my own workstation, it remained enabled on my File Server. *shrugs*

Since adding the full path of each version's install of acad.exe to Trend's allowed/trusted programs, which affects both desktop and server instance of Trend, I haven't had a single issue ... Too bad I don't have someone as smart as RJP running my network ... Off to re-enable Google Drive, etc. for completeness.

Cheers, ninja! :beer:

[BlackBox]

Quick update -

It ends up that the cause isn't Trend either - while it should have the resultant configuration in testing for this, it *appears* that the cause may actually instead be our Syncovery backup software's 'Real-Time Sync' service running on the file server (which syncs non-empty data to another physical server's share for CYA).

Stopping the aforementioned service seems to preclude the issue from happening (it's only been stopped for a short time this morning), so we'll see.



If this proves to be the cause, then I'll have to look into either scheduling the service, as opposed to being done in real-time, or even transition to Windows Server's in-built shadow copies (which yields the same CYA).

Cheers

[BlackBox]

It wasn't the real-time sync either.

I ended up noticing that there was a small time discrepancy between my cell phone and my PC (well, all servers, and clients, as they're synced w/DC), which kerberos seems to have taken great issue with.

I manually made the change to time and date within the DC (domain controller [virtual], which is also my time server for the domain), but saw time 'slipping' following Windows updates, etc. and would again have to manually change settings to correct, despite my time server being synced with MS' time server.

I traced the issue to the logon script that I inherited, which was originally employed with our previous Windows Server 2003/2008 R2 environment, and called

Code: [Select]

net time <DomainController> /set /y

This isn't necessary with modern time server (W32TM) implementation, and ultimately caused the time bust across the domain (more to it, but that's the takeaway).

In any event - the issue has been resolved now for a week or so, without another instance cropping up... and the server is generally operating much better in terms of performance with the same 5-80 MB drawings... so, yay.

Cheers

[pkohut]

Handle might help next time -
https://technet.microsoft.com/en-us/sysinternals/bb896655.aspx

[BlackBox]

Handle might help next time -
https://technet.microsoft.com/en-us/sysinternals/bb896655.aspx

Much appreciated. :beer:

[rkmcswain]

2 days ago I had the problem until I could delete the dwl files, so that sugguests a lock to me, or is the workstation locking these too.  Acad 2016 here.

The O/S doesn't know or care about the presence or absence of .DWL* files.

This can be demonstrated like this:
1. Open a DWG
2. See the .DWL* files get created in Explorer.
3. Use Task Manager to kill "Acad.exe"
4. The .DWL* files remain in place.
5. Re-open AutoCAD and open the DWG, it will not be "read-only" because of the .DWL* files.