Delete Autosave

Delete Autosave

Anonymous
Not applicable
65,110 Views
118 Replies
Message 1 of 119

Delete Autosave

Anonymous
Not applicable
Apparently AutoCAD will delete the autosave if it feels it was shut down
correctly. Well mine crashed yesterday and the autosaves were all deleted
so I ended up losing all my work since the previous qsave. I would like to
know if there is a variable for this or a way we could change it to just
never delete? I would be glad to manually purge the directory, but I never
want what happened yesterday to happen again. It makes autosave rather
pointless in my book.

--
Dr. After
0 Likes
65,111 Views
118 Replies
Replies (118)
Message 101 of 119

Anonymous
Not applicable
*Luis Esquivel* typed them thar words:

| latest....

I'm tied up this morning, but I will give it some good test runs here in
about an hour and let you know what I find out. Thanks!

--
Dr. After
0 Likes
Message 102 of 119

Anonymous
Not applicable
doesn't seem to work on multiple drawings....
actually... this one doesn't seem to be working at all.

--
Dr. After
0 Likes
Message 103 of 119

Anonymous
Not applicable
Mine is not working also...been testing all morning.
This is what I have been using...it did create the folder.

;;;by Luis Esquivel
(defun ARCH:AutoSave-test ()
(princ "\n*** AutoSave to -> C:\\Arch_Custom\\AutoSave ***")
(vl-mkdir "C:\\Arch_Custom\\AutoSave\\"))
;; this appears to work on an MDI system
;; open more than one drawing(s) and load the
;; reactor on each of them, to test this
(defun copy_sv$ (reactor params / files file)
(if (and (setq files (vl-directory-files (getvar "SAVEFILEPATH")
"*.SV$"))
(setq file (vl-some
(function
(lambda (dwg)
(if (wcmatch
dwg
;; here we need to find a much viable
system
;; in order to return our desired
drawing,
;; since autosave files will use
XXXXXX1_11_11.SV$
;; or something like that
;;
;; do your own changes here
(strcat "*" (substr (getvar "DWGNAME") 1
9) "*"))
dwg)))
files)))
(progn ;; make a copy of SV$ file into the c:\\autosave folder
;; as a drawing extension with the OUT_ prefix
(vl-file-copy
(strcat (getvar "SAVEFILEPATH") "\\" file)
(strcat "C:\\Arch_Custom\\AutoSave\\" "OUT_" (getvar
"DWGNAME")))
;; delete previous BAK_ file
(vl-file-delete
(strcat "C:\\Arch_Custom\\AutoSave\\" "BAK_" (getvar
"DWGNAME")))
;; rename the new OUT_ file with the BAK_ prefix
(vl-file-rename
(strcat "C:\\Arch_Custom\\AutoSave\\" "OUT_" (getvar
"DWGNAME"))
(strcat "C:\\Arch_Custom\\AutoSave\\" "BAK_" (getvar
"DWGNAME")))
;; delete OUT_ file
(vl-file-delete
(strcat "C:\\Arch_Custom\\AutoSave\\" "OUT_" (getvar
"DWGNAME"))))))
(if (not dwg_reactor)
(setq dwg_reactor (vlr-dwg-reactor nil '((:vlr-beginsave . copy_sv$)))))
(princ))
(ARCH:AutoSave-test)

--
Gary Fowler - Architect
gdfowler@hotmail.com
"Dr. After" wrote in message
news:4864855@discussion.autodesk.com...
doesn't seem to work on multiple drawings....
actually... this one doesn't seem to be working at all.

--
Dr. After
0 Likes
Message 104 of 119

Anonymous
Not applicable
Hi (name?),

I have also seen these files go poof, usually due to operator error but not
always. Not to detract from others suggestions, this code I've posted
before ( http://discussion.autodesk.com/thread.jspa?messageID=4295603 )
might also help. I believe this is very similar to what Luis posted, but I
haven't studied his so this may or may not have anything additional to
offer.
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO

[code]
;;; If AutoCAD's autosave feature is turned on, this code maintains a
;;; copy of the .sv$ file.
;;; It will copy the file whenever (1) a command is issued and (2) the time
;;; increment specified by the savetime system variable has passed
;;; (since the file was opened or the last copy, whichever is shorter).
;;;
;;; This entire code should be loaded from a single file for each document
opened.
;;; For example, typically acaddoc.lsp would load a file containing this
code.
(vl-load-com)
;;; Getvar using ActiveX
(defun MWE:GetVar (arglst)
(vlax-invoke ActiveDocument 'GetVariable arglst)
)
;;; AutoSave makes a copy of AutoCAD's current autosave file.
(defun MWE:AutoSave (rxrnm cmdinf / ActiveDocument date file1 file2)
(setq ActiveDocument (vlax-get (vlax-get-acad-object) 'ActiveDocument)
date (MWE:GetVar "date")
file1 (findfile (MWE:GetVar "savefile"))
)
(if (and file1 ASV:TimeToSave (>= date ASV:TimeToSave))
(progn
(setq file2
(strcat
(vl-string-right-trim "\\" (MWE:GetVar "savefilepath"))
"\\AutoSave "
(MWE:GetVar "dwgname")
)
)
(prompt "\nBacking up autosave file ... \n")
(if (findfile file2)
(vl-file-delete file2)
)
(vl-file-copy file1 file2)
(setq ASV:TimeToSave nil)
)
)
(if (not ASV:TimeToSave)
(setq ASV:TimeToSave (+ date (/ (MWE:GetVar "savetime") 1440.0)))
)
(princ)
)
;;; Load the AutoSave Reactor
(vlr-command-Reactor
"Command reactor"
'((:vlr-commandWillStart . MWE:AutoSave))
)
(princ)
[/code]


"Dr. After" wrote in message
news:4861667@discussion.autodesk.com...
Apparently AutoCAD will delete the autosave if it feels it was shut down
correctly. Well mine crashed yesterday and the autosaves were all deleted
so I ended up losing all my work since the previous qsave. I would like to
know if there is a variable for this or a way we could change it to just
never delete? I would be glad to manually purge the directory, but I never
want what happened yesterday to happen again. It makes autosave rather
pointless in my book.

--
Dr. After
0 Likes
Message 105 of 119

Anonymous
Not applicable
Short of waiting for "natural selection" to produce a more intelligent species very little. Proper training in the proper use of SAVE and QSAVE will reduce the occurrence this particular mistake. So will automating the SAVE and QSAVE commands by attaching them via programming to other commands like ZOOM or PAN or hiding QSAVE behind popular button commands so that it will execute each time the button is selected.
0 Likes
Message 106 of 119

Anonymous
Not applicable
Yep,

That is why I put a note:

;; here we need to find a much viable
system
;; in order to return our desired
drawing,
;; since autosave files will use
XXXXXX1_11_11.SV$
;; or something like that
;;
;; do your own changes here
(strcat "*" (substr (getvar "DWGNAME") 1
9) "*"))
dwg)))
0 Likes
Message 107 of 119

Anonymous
Not applicable
>>Ok. I would like to put all the blame on the fool who forgot to save.

Good, that's where it belongs.


> How do I prevent human error in the future? Isn't that what you are telling me I should "fix"? Then give me a solution to it.

Proper training in the proper use of the tool.


> I can tell ther user to always use qsave but we all know words do not control another human being.

Maybe not, but consequences can alter behavior radically. everyone here knows that they'd better be saving often, because if they don't there will be consequences. I dislike lost data, I dislike it immensely, losing data will draw my ire. Lose it often enough and it'll draw a pink-slip.


> I could fire the guy, but then I have to replace them with someone green.

Drawing employment "blood" is a last resort, but sometimes a pink-slip is necessary to solve an individual problem. It will also give a clear warning to those that remain that the infraction will be taken seriously.
0 Likes
Message 108 of 119

Anonymous
Not applicable
*OLD-CADaver* typed them thar words:

| Short of waiting for "natural selection" to produce a more
| intelligent species very little.


Side Note: Due to medical advances, political correctness and sympathy,
Darwin's theory is no longer a large factor when it comes to humans as we
are now enabling the weaker of us to continue to survive and even more
scary, reproduce. We are hindering our own evolution due to sympathy for
the weak.


| Proper training in the proper use
| of SAVE and QSAVE will reduce the occurrence this particular mistake.

Mind if I send them over to McKnight Ln to get er done right?
;-)

| So will automating the SAVE and QSAVE commands by attaching them via
| programming to other commands like ZOOM or PAN or hiding QSAVE behind
| popular button commands so that it will execute each time the button
| is selected.

Now that's some darn good old school idea that noone else had mentioned yet
in this thread. Though I thought of using this, it tends to slow down
common commands and is still relies that you use these commands. I would
rather use the script method based on time or number of commands.

You know it's funny, I did find another thread where someone else
had the same issue as I. And sure enough, you were in the thread trying to
convince them that their scenario did not happen to them and you only
offered the advise of use qsave or die... or something like that. I think
this last idea you posted is more helpful then beating to death the idea
that qsave is the only option and that losing work past the SAVETIME value
is not possible.

--
Dr. After
0 Likes
Message 109 of 119

Anonymous
Not applicable
Well... in my opinion, it is the CAD Managers duty to see that any avoidable
error is avoided. In fact, having the knowledge that it could happen and
conciously neglecting to correct the potential problem and allowing it too
happen just to prove a point that they should qsave often is grounds for
termination in my book. You allow yourself to be an accessory, if not even
a promoter of the problem at hand just to train a habit that could have been
trained via a safer method. It just seems poor judgement from my
perspective. It's baiting the employee while costing the company money.

--
Dr. After
0 Likes
Message 110 of 119

Anonymous
Not applicable
Okay,

Since I am not familiar on how the autosave naming is, I was assuming that the file is truncated, now for the drawings have open here, appears that the filename base is kept, please do your own corrections on this.

Here is the latest:
[code]
;; 10:07 AM 6/1/2005 LE
;; 12:45 AM 6/2/05 LE
;; 3:06 PM 6/2/05 LE
;; 9:55 AM 6/3/05 LE

(vl-load-com)

(if (not (vl-file-directory-p "C:\\AUTOSAVE\\"))
(vl-mkdir "C:\\AUTOSAVE\\"))

;; this appears to work on an MDI system
;; open more than one drawing(s) and load the
;; reactor on each of them, to test this
(defun copy_sv$ (reactor params / files file)
(if
(and (setq files
(vl-directory-files (getvar "SAVEFILEPATH") "*.SV$"))
(setq file
(vl-some
(function
(lambda (dwg)
(if
(wcmatch
dwg
(strcat "*"
(vl-filename-base (getvar "DWGNAME"))
"*"))
dwg)))
files)))
(progn

;; make a copy of SV$ file into the c:\\autosave folder
;; as a drawing extension with the OUT_ prefix
(vl-file-copy
(strcat (getvar "SAVEFILEPATH") "\\" file)
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME")))

;; delete previous BAK_ file
(vl-file-delete
(strcat "C:\\AUTOSAVE\\" "BAK_" (getvar "DWGNAME")))

;; rename the new OUT_ file with the BAK_ prefix
(vl-file-rename
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME"))
(strcat "C:\\AUTOSAVE\\" "BAK_" (getvar "DWGNAME")))

;; delete OUT_ file
(vl-file-delete
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME"))))))

(if (not dwg_reactor)
(setq dwg_reactor
(vlr-dwg-reactor nil '((:vlr-beginsave . copy_sv$)))))

(princ)
[/code]
0 Likes
Message 111 of 119

Anonymous
Not applicable
> Well... in my opinion, it is the CAD Managers duty to see that any avoidable error is avoided.

That is very true, the CAD manager should properly train his people in th proper use of the tools.


> In fact, having the knowledge that it could happen and
conciously neglecting to correct the potential problem and allowing it too happen just to prove a point that they should qsave often is grounds for termination in my book.

Any manager that has failed to properly train his people "just to prove a point" should be terminated. But then again, any manager that has failed to properly train his people PERIOD, should be terminated.


> if not even a promoter of the problem at hand just to train a habit that could have been trained via a safer method.

No one here, including me has ever promoted the idea of allowing someone to remain untrained to "prove a point" or to "train a habit". We properly train our people PRIOR to turning them loose on our drawings.


> It just seems poor judgement from my perspective. It's baiting the employee while costing the company money.

Any manager doing so, should be terminated. No one has ever promoted doing so.
0 Likes
Message 112 of 119

Anonymous
Not applicable
Thanks. It is working now.


Also this one.....MWE:AutoSave
See-->James Allen post in this thread.


I will continue to test both over the weekend.
Thanks again, Luis for your hard work and Allen for the post.

--
Gary Fowler - Architect
gdfowler@hotmail.com
wrote in message news:4865029@discussion.autodesk.com...
Okay,

Since I am not familiar on how the autosave naming is, I was assuming that
the file is truncated, now for the drawings have open here, appears that
the filename base is kept, please do your own corrections on this.

Here is the latest:
[code]
;; 10:07 AM 6/1/2005 LE
;; 12:45 AM 6/2/05 LE
;; 3:06 PM 6/2/05 LE
;; 9:55 AM 6/3/05 LE

(vl-load-com)

(if (not (vl-file-directory-p "C:\\AUTOSAVE\\"))
(vl-mkdir "C:\\AUTOSAVE\\"))

;; this appears to work on an MDI system
;; open more than one drawing(s) and load the
;; reactor on each of them, to test this
(defun copy_sv$ (reactor params / files file)
(if
(and (setq files
(vl-directory-files (getvar "SAVEFILEPATH") "*.SV$"))
(setq file
(vl-some
(function
(lambda (dwg)
(if
(wcmatch
dwg
(strcat "*"
(vl-filename-base (getvar "DWGNAME"))
"*"))
dwg)))
files)))
(progn

;; make a copy of SV$ file into the c:\\autosave folder
;; as a drawing extension with the OUT_ prefix
(vl-file-copy
(strcat (getvar "SAVEFILEPATH") "\\" file)
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME")))

;; delete previous BAK_ file
(vl-file-delete
(strcat "C:\\AUTOSAVE\\" "BAK_" (getvar "DWGNAME")))

;; rename the new OUT_ file with the BAK_ prefix
(vl-file-rename
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME"))
(strcat "C:\\AUTOSAVE\\" "BAK_" (getvar "DWGNAME")))

;; delete OUT_ file
(vl-file-delete
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME"))))))

(if (not dwg_reactor)
(setq dwg_reactor
(vlr-dwg-reactor nil '((:vlr-beginsave . copy_sv$)))))

(princ)
[/code]
0 Likes
Message 113 of 119

Anonymous
Not applicable
*OLD-CADaver* typed them thar words:

| Any manager doing so, should be terminated.

So you agree. Any CAD Manager that:

1) knows you shouldn't rely on AutoCAD's autosave
2) is aware there are scripts available to prevent loss if someone doesn't
qsave often enough
3) is aware that humans are prone to making a mistake no matter how diligent
and repetitive they are

...and does not implement one of these failsafes as they would rather hope
none of their drafters ever makes a mistake due to the superior training
provided by the CAD Manager, then that CAD Manager should be terminated.

Have you spoken with your boss about terminating yourself lately?

Leaving that opportunity available is just asking for trouble, if you ask
me.

--
Dr. After
0 Likes
Message 114 of 119

Anonymous
Not applicable
Hi James,

The idea of the last approach I did, was to come up with a single back-up copy made from all possible autosave files, that belong to a particular drawing.

LE.
0 Likes
Message 115 of 119

Anonymous
Not applicable
> We are hindering our own evolution due to sympathy for the weak.

Meaning we are allowing those who fail to SAVE properly to survive in our employ?


> Mind if I send them over to McKnight Ln to get er done right?
;-)

Send 'em on. Be warned my wife is an excellent shot, saving a drawing will be easy compared to surviving the visit.


> I did find another thread where someone else had the same issue as I. And sure enough, you were in the thread trying to convince them that their scenario did not happen to them.

Look a little harder there are 4 or 5 threads where people have confused the function of AutoSAVE and made claims contrary to the programming. It is natural for people to blame the tool instead of blaming themselves for their own errors. And yes, I took the opportunity to educate them on the functions of the tool.


> I think this last idea you posted is more helpful then beating to death the idea that qsave is the only option

Only option?... no don't think I said it was the "only" option. Most intelligent option, now that I may have said. If you wish to save time retrieving lost data (even when the $SV is there) it is the only option that does not require programming.


> and that losing work past the SAVETIME value is not possible.

Wait a minute, who said that? Losing data "PAST" the SAVETIME is completely possible, in fact that is precisely how AutoSAVE works. Anything created/modified between the last SAVE or AUTOSAVE and the crash is lost irretrievably. The very best you can recover is up to the last SAVE or AutoSAVE.
0 Likes
Message 116 of 119

Anonymous
Not applicable
Hi Luis,

How goes? I decided to study your code a little and have some feedback for
you (and for the benefit of others as well).

(... vl-directory-files ... vl-some ... wcmatch ...)
This portion of your code may get a file you don't want. If there are old
autosave files left over from previous sessions with the same file name, you
may get one of them instead of the one for the active drawing. That is why
I use the savefile system variable.

(... copy ... delete ... rename ... delete ...)
I see yours is better than mine here, as it makes sure that there is at
least one copy at any given point in the process. Mine just deletes the old
and copies the new. I'm not sure though why you have the final delete call,
as the file won't be there since you just renamed it.

(... :vlr-beginsave ...)
I don't think this choice of a trigger would have helped in the OP's stated
situation, because it depends on having done a save. In the situation
(which I have seen more than once) where you've gone too long without saving
(yes, messed up in the first place) and AutoCAD up and disappears taking the
built in autosave with it, then you still don't have any autosave.
I like the :vlr-commandWillStart trigger because this is almost always when
drawing changes will take place. And I put the timer function in mine
because the autosave file won't change more often than that anyway. So it
triggers on every command, but does nothing until the savetime has elapsed.

There is also one issue in mine that was pointed out to me before by Andreas
and will also affect yours. In MDI, if muliple files of the same name are
open, our autosave reactors will only maintain a single backup for the
multiple files based on the file name. I haven't bothered to account for
this in mine because that would be such a rare occasion here. But others
may need to take that into account. I think this would be as simple as
using savefile in place of dwgname for the backup, minding file extensions
or prefixes to avoid naming conflicts.
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO


wrote in message news:4865029@discussion.autodesk.com...
Okay,

Since I am not familiar on how the autosave naming is, I was assuming that
the file is truncated, now for the drawings have open here, appears that
the filename base is kept, please do your own corrections on this.

Here is the latest:
[code]
;; 10:07 AM 6/1/2005 LE
;; 12:45 AM 6/2/05 LE
;; 3:06 PM 6/2/05 LE
;; 9:55 AM 6/3/05 LE

(vl-load-com)

(if (not (vl-file-directory-p "C:\\AUTOSAVE\\"))
(vl-mkdir "C:\\AUTOSAVE\\"))

;; this appears to work on an MDI system
;; open more than one drawing(s) and load the
;; reactor on each of them, to test this
(defun copy_sv$ (reactor params / files file)
(if
(and (setq files
(vl-directory-files (getvar "SAVEFILEPATH") "*.SV$"))
(setq file
(vl-some
(function
(lambda (dwg)
(if
(wcmatch
dwg
(strcat "*"
(vl-filename-base (getvar "DWGNAME"))
"*"))
dwg)))
files)))
(progn

;; make a copy of SV$ file into the c:\\autosave folder
;; as a drawing extension with the OUT_ prefix
(vl-file-copy
(strcat (getvar "SAVEFILEPATH") "\\" file)
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME")))

;; delete previous BAK_ file
(vl-file-delete
(strcat "C:\\AUTOSAVE\\" "BAK_" (getvar "DWGNAME")))

;; rename the new OUT_ file with the BAK_ prefix
(vl-file-rename
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME"))
(strcat "C:\\AUTOSAVE\\" "BAK_" (getvar "DWGNAME")))

;; delete OUT_ file
(vl-file-delete
(strcat "C:\\AUTOSAVE\\" "OUT_" (getvar "DWGNAME"))))))

(if (not dwg_reactor)
(setq dwg_reactor
(vlr-dwg-reactor nil '((:vlr-beginsave . copy_sv$)))))

(princ)
[/code]
0 Likes
Message 117 of 119

Anonymous
Not applicable
Hi James,

Thank you so much for all your feedback, the routine for me is now done.

If I have a chance, I would get into the points you mentioned, again thank you and come back to posted here the resulting code.

I also provided previously or in an early respond here, another alternative, and it was close to what master Jeff did using VBA... anyway it was not good too.

Also for any other lisper, the code is open source, make it suit your needs.

About the last delete call, I just copied parts of another code I had, and just did not saw that.... 😞

Have fun, 🙂
Luis.
0 Likes
Message 118 of 119

Anonymous
Not applicable
I'v tried following this thread but I keep getting lost. Is there a way to
have autosave or to redefine the qsave to only exicute the save after "x"
number of commands such as pline line zoom ect.? The reason I ask is
because there are alot of times that it helps to have multipl drawings open
and switch back and forth. Somethimes these drawing are large. When
AutoCAD autosave initiats a save on a drawing in the background nothing has
been done to it so there is no need to do a save.

Thanks in advance.
Daren

wrote in message news:4865310@discussion.autodesk.com...
Hi James,

The idea of the last approach I did, was to come up with a single back-up
copy made from all possible autosave files, that belong to a particular
drawing.

LE.
0 Likes
Message 119 of 119

Anonymous
Not applicable
Look for Jeff Mishler solution it is a VBA code.


I'v tried following this thread but I keep getting lost. Is there a way to
have autosave or to redefine the qsave to only exicute the save after "x"
number of commands such as pline line zoom ect.? The reason I ask is
because there are alot of times that it helps to have multipl drawings open
and switch back and forth. Somethimes these drawing are large. When
AutoCAD autosave initiats a save on a drawing in the background nothing has
been done to it so there is no need to do a save.
0 Likes