VL-File functions and Microsoft

rwills2691

I have come across this by working with Windows 10. On account of a recent upgrade Windows no longer permits certain VL-File functions if you are trying to work with files that are in different folders. The following is an example

`
(if (> cnt 1)
(progn ;; new data was created

   ;; (vl-file-delete ActiveData)  ;; DID NOT WORK DUE TO SECURITIES ON EXTERNAL FOLDERS
   ;; (vl-file-rename FileCopy ActiveData)  ;; DID NOT WORK DUE TO SECURITIES ON EXTERNAL FOLDERS

   ;; OPTIONALLY:
   ;; (vl-file-copy FileCopy ActiveData)  ;; DID NOT WORK DUE TO SECURITIES ON EXTERNAL FOLDERS

   ;; ALTERNATELY:
   (setq dskcpy (open FileCopy "r")) ;; READ ONLY
   (setq dskdat (open ActiveData "w")) ;; READ WRITE
   (while (setq ReadData (read-line dskcpy))
          (write-line ReadData dskdat)  
          )
   (close dskcpy)
   (close dskdat) 
   (vl-file-delete FileCopy)       
   )
)

`

The alternately section is what I have done to overcome the problem. The last code exhibits that FileCopy, which is in a working folder, can be deleted. But the upper command by the same will not delete the file. More marvelous innovations by the genius' of Microsoft. They should leave security to the 3rd party vendors.

The commented code had worked a few weeks ago.

Rick

rwills2691

Please exuse the goofy looking code. I tried to use the CODE formatting function again.

Rick

Jason Bourhill

Are you sure the files specified are available to do what you want to do?
Why would

(vl-file-delete ActiveData) not work, but
(vl-file-delete FileCopy) does?

I tried a test with
(vl-file-copy (getfiled "Drawing file to copy" "" "dwg" 0) (getfiled "Enter new drawing name" "" "dwg" 1)) (vl-file-delete (getfiled "Drawing file to DELTE" "" "dwg" 0))
on an external drive and it worked without issue.

Not working in Dropbox, google drive... type folders? These can cause problems with applications as they can lock up files.

Regards,
Jason Bourhill
CAD Concepts

rwills2691

I spent an entire day trying to track down the malfunction. Once I had determined that it was the VL functions I decided to write the "alternately" code to bypass their use. I was copying a file in one folder that holds all of my utilities (separate from the functionality of BricsCad) to a folder that holds my drawing data.

The VL-Delete would delete files from my Utility Folder, but not a file in the Drawing Folder. The VL-Rename and VL-Copy functions would not work in either of the folders.

Since they all worked last week, I have to assume that it was a security issue, but I could not find a way to increase the Admin rights to the VL functions. Trying to do so for BricsCad itself did not help.

Due to the goofy Microsoft rules for security, it is possible that there can be different results with different computer installations. Likewise, the update to my computer was few days ago.

It is also possible that your use of the GetFiled function had satisfied securities, since the demand is native to the code string. I was using variables instead. They might regard variables as a hack.

Rick

rwills2691

Now I am finding that all of my own ActiveX/OLE apps are requiring higher elevation for security. It is definitely a security issue due to recent Windows 10 upgrades.

Rick

rwills2691

I have managed to elevate BricsCAD, and that has allowed my ActiveX exe's to work. I have work to do, and I don't care about VL-File routines. I am sticking with my "alternative" code. I Don't like VL stuff anyway. I also hate the dummies at Microsoft. They are kids sucking on lollipops.

Rick

rwills2691

In trying to print to a PDF I discovered that it would not print by the Plot Styles Table. Investigating I discovered that the drawing file was corrupted. I saved it by copy/pasting everything to a new (blank) drawing. I think that this has been the source of all the problems... it just chanced to happen subsequent to the Windows update. I have no idea of what had actually caused the corruption.