Tool Palette Use Creates Drawing Lock File in Source Directory

[sbrusco]

Hi All,

I have a tool palette that contains 16 tools to insert 16 dynamic blocks that are all in the same source directory. When the users pick on a tool icon then pick in the drawing to insert the block. Typical use, right?

As soon as the block is inserted, the  *.DWL file is created in the directory that holds the source, dyn block drawings. All users have read-only rights to this directory so this further confounds me as to how they can create any kind of a file there.

I have attached an image of one of the tool's properties so you can see there is nothing fancy going on.

Can anyone tell me why this is happening? Or more importantly, how to make it stop?

TIA,

Sal

[rkmcswain]

.DWL (and .DWL2) files are *not* lock files. These only exist to facilitate the WHOHAS command.

[sbrusco]

Hi RK,

Thanks for your quick response.

Okay, so they're called "WHOHAS" files. They're still created in a directory, by a user that does not have write permissions in that directory. As the one responsible for maintaining those blocks, that is my problem but the bigger question, or at least as big a question is, why does inserting these blocks from the tool palette even think it needs to open a "WHOHAS" file in the first place? Doesn't this palette use just "insert" the block?

[rkmcswain]

When I insert a block (.DWG file) from a palette button, I see the .DWL and .DWL2 files get created in the folder that contains the .DWG.

They remain until I drop/place the block, then they go away.

I highly suspect the folder that contains your blocks has WRITE and MODIFY rights, but not DELETE rights. Which is why the .DWL and .DWL2 files are being retained.

[rkmcswain · Accepted solution]

Here is a screencap animation on my system.

Double check your permissions on these folders. 

Is this a pure windows server? Or a SMB share off of a NAS box?

[rkmcswain]

sbrusco wrote:

.... why does inserting these blocks from the tool palette even think it needs to open a "WHOHAS" file in the first place? Doesn't this palette use just "insert" the block?

I'm no O/S expert by any means, but if AutoCAD wants to insert the drawing, the file contents have to be "read", which means there is a [file open, file read, file close] process that takes place.

And while the file is open, the .DWL and .DWL2 files will exist.

Consider if a user clicks the button to insert the block, then the phone rings before he/she places the block, and then he/she gets up and leaves for the day. That file is literally "open" until it's closed, and someone at Autodesk determined to not close the file until it is placed in the drawing. (I suppose they could have programmed it to open the file, read the file, and close the file, all in one quick succession)

As to how the .DWL and .DWL2 files get created in a read-only target location? The users must have write access at some level.

I just changed the permissions on my target folder, so that I do not have Write access, and the .DWL & .DWL2 files do not get created. Process Monitor tells me that AutoCAD still tried to create them, but that the access was denied.

[sbrusco]

RK, thanks so much for the visual. I still don't know why Adsk didn't make this a more transparent process and wouldn't believe it if I didn't just see it.

I have been working in this company's environment for almost 15 years and can say I have never seen this before. I have been using this drive as a repository for all my CAD blocks and as far as I know, the permissions on the drive have not changed. That being said, why have I never seen these orphaned DWL(2) files in the past???

Off I go our IT department to as them why. About 2 years ago, we were bought by another company and it may have taken that long for them to start controlling directory permissions. I don't know.

Thanks again for the response and, I'll say, the answer.

Sal