SV$ files
e.g.
275P_5178.SV$, autosaved from 275/dwg/275P.dwg, would be filed in 275/dwg/sv$
300D_6516.SV$, autosaved from 300/dwg/300D.dwg, would be filesd in 300/dwg/sv$
etc.
Comments
-
since there is only one autosave path per "autocad profile", you would either have to have multiple profiles - yuk, or do something on startup. By far, I would use the startup, specifically a file you create called On_doc_load_default.lsp. It loads for each drawing, and acad looks for it using support paths, so make that .lsp file and put its containing folder as first path in support paths. Then in the .lsp, you add some logic to get the current drawing name, and tweak the autosave path using it.
The code in the .lsp (just a text file named .lsp) looks like this:
(vl-load-com)
(SETQ AOBJ (vlax-get-acad-object)
APREF (vla-get-Preferences AOBJ)
APREFUSER (vla-get-User APREF)
AFILES (vla-get-Files APREF)
)
(vla-put-AutoSavePath AFILES (getvar "dwgprefix"))so the (getvar "dwgprefix") is the autosave path. Test that at the command line to see it work.
controlling the settings of acad on startup is something many, many, people do so set that secureload to 0 and use the .lsp.
0 -
Similar post here on setting Plot settings
http://forum.bricsys.com/discussion/20342
Beware that BricsCAD is a multi document interface (MDI). You may get unexpected results, or at least confused if you open drawings from several different projects at once. on_doc_load.lsp loads each time you open or start a new drawing, so it will be your most recently opened drawing that will dictate the Autosave location. i.e. AutoSavePath is a preference, it's not saved in your drawing, as such you should consider it as a global variable.
An alternative would be to set your Autosave location to a specific folder e.g. 'C:\BCAD\Autosave'
Regards,Jason Bourhill
0 -
Actually there is a similar function in Express Tools called MOVEBAK to move all .bak files to a particular folder. with SV$ you want the opposite. Perhaps someone has done a LISP for that? Move the .SV$ from it's fixed location to a folder relative to the current .dwg. This would probably be a better approach than directly changing the AutoSavePath.Regards,Jason Bourhill0
-
oh, very good point about the MDI. My approach is not good enough for multiple drawings from different folders in one session..
So to make the proper tool, you would use .net and the document activated event to change the path. Its funny because while .net is a deeper pool to swim in, there is not lisp debugger in Bcad like the VLIDE for acad, but you can debug .net just fine using visual studio. The poor OP is getting depressed about now hearing us talk about events and stuff, so someone needs to make a little .net prog that adjusts variables and things stored in a text file, every time a drawing is switched to.
The other funny thing is I will propose that to the autodesk development team, then they do the example and all the bcad people can use it. The code is the same.
it would be easy to make a lisp command that is run manually to move the .sv$ files, except that how would you filter so you just get the ones pertaining to the drawings folder?
0 -
it would be easy to make a lisp command that is run manually to move the .sv$ files, except that how would you filter so you just get the ones pertaining to the drawings folder?
In this case I don't think you need to react to switching documents, Instead create a document reactor that monitors changes to 'SAVEFILE', which is used to store the autosave filename. When this changes you know an autosave has occured, and also the filename :-)
BTW I live fine without a debug tools, but then I come from a time before VLIDE...... Shuffles off with walking frame.Regards,Jason Bourhill0 -
??? the sv$ files are saved in the setting "save file path" . I have set it to x:\backup since way back.0
-
Sorry I have to read as well.
0 -
Wow thank you boys. Is that the final word, to make sense of, or is there some other possibility in the pipeline?
Actually Jason's idea 'to set your Autosave location to a specific folder e.g. 'C:\BCAD\Autosave'' could be a good stopgap at least.
Signed - "the poor OP".0 -
I am puzzled why you want to keep changing the SV$ file. Perhaps there is an advantage to moving them that I am unaware of.The ZV& files are only an "emergency back" file to be use if BricsCAD crashes. Normally, when BricsCAD exits properly, the SV$ files are deleted. By having them in one spot, you can go to that directory, and delete all the accumulated SV$ files that were abandoned there over the years. If they were scattered, they are more difficult to hunt down in mass, and they will get backed up when ever you back up your data.-Joe0
-
I often enough find it invaluable to have a stock of 'previous versions' that I can pick things from if I find something's gone wrong or deleted. bak files are useless for that - usually only half a day older than the dwg. I hope the sv$'s aren't auto-deleted - how can I stop that happening?0
-
keep in mind, proper behavior is for the autosaves to be deleted on every successful save.
You would have to get a bit exotic to alter that.
0 -
I hope the sv$'s aren't auto-deleted - how can I stop that happening?
As far as I can tell BricsCAD doesn't auto delete these files. However AutoCAD documents that it does, so you may find BricsCAD changes to follow suit at some point. Also depending on your SAVETIME setting, it is possible that an autosave file may never get created. Atosave is only triggered if you haven't done a SAVE yourself. Every time you do a SAVE the autosave timer is reset, so if you SAVE regularly and have large SAVETIME value, then an autosave file may only ever be created occasionally. The default SAVETIME value is 60mins, which I typically reduce to a more realistic 10 - 15mins.
At the end of the day I wouldn't rely on Autosave or BAK as a form of backup. They are really only useful immediately around an event such as BricsCAD crashing, or you having an "oh shit, I shouldn't have deleted that" moment. If you want to capture a project at key points such as design change, issue for construction etc. Then I suggest you investigate ETRANSMIT. This isn't an automated command, but is very good for capturing everything (xrefs, images, fonts, plotcfg...) related to a project at a particular point. If you use in conjunction with Sheetsets, then you can capture multiple drawings at once.
Regards,Jason Bourhill
0 -
Thanks Jason.
When I was using Acad, I had just the same goodly selection of sv$'s to turn to when needed - I see no difference between Acad and Bricscad in that respect. I hope it stays this way.0 -
Jason is right, I posted about this in 2003 and to me its still a minor issue.
0 -
If your goal is to have backups of various versions of your drawings, why not just use a backup utility. Most backup utilities can be set to look in specific directories, for specific kinds of files. Then, they can be set to backup only the files that have changed since the last backup. This is called an incremental backup. You could set it to run, perhaps every day or even a few times a day.This would probably be a lot easier and better than using some sort of custom programming in BricsCAD to deal with SV$ files.-Joe0
-
I have set my backup file location (i.e. savefilepath) to C:\Program Files\Bricsys\Backup Files\ (and the folder does exist) but BricsCad does not use this folder but rather saves the .bak and .SV$ to C:Users\Bill\AppData\Local\Temp\BricsCad. IT's not a huge BUT it would be nice to have the variable (savefilepath) actually work. Does nayone have a solution?0
-
It's working fine for me now - all .sv$s save to E:\My Drawings\Autosave, as handy as I can get to say E:\My Drawings\296 Bellever\dwg0
-
I just changed the savefilepath variable for backup files from C (where BricsCad is located) to D. Now the .bak and .SV$ files are going into this new directory. Maybe that's the trick...you have to change to a new drive and not just to a new folder on the original drive??0
-
That would be worth a bug fix/improvement Service Request.0
-
@ William: This problem may also be caused by the OS. It is perhaps a user permissions issue.0
-
@William: Agree with Roy, it is very likely to be your OS, not BricsCAD causing your issue. From around Windows Vista on the 'Program Files' folder typically requires elevated privileges to write to. Unless you run BricsCAD with elevated privileges (you really don't want to do this), then your selected folder will be seen as read-only, and BricsCAD will revert to default settings. For options such as this I recommend that you select a different location such as 'C:\BCAD\Backup Files\'
Regards,Jason Bourhill
0 -
Roy, Jason: Thanks for the input. This makes sense and is consistent with the result I had by changing to drive D. I'll try it on drive C (other than the "Program Files" directory).0
-
I am a little vague on the details in my particular situation, but our tech support guy said BricsCAD must be run so that Windows 7 always prompts me to give permission for BricsCAD to modify the computer. The BricsCAD shortcut, is set so that BricsCAD runs "as administrator". Though, there is only one user account on this computer, which is an administrator.Perhaps your situation is the same, and it has not been set to do that.-Joe0
-
I am a little vague on the details in my particular situation, but our tech support guy said BricsCAD must be run so that Windows 7 always prompts me to give permission for BricsCAD to modify the computer. The BricsCAD shortcut, is set so that BricsCAD runs "as administrator". Though, there is only one user account on this computer, which is an administrator.Perhaps your situation is the same, and it has not been set to do that.-Joe
Sounds like you are using an older version of BricsCAD that had an .exe installer. This could create user access issues depending on how it was originally installed. Later releases have moved to a .msi installer that seems to have resolved these issues. The only time you may need to 'run as administrator' is when you initially enter your license key. Other than that it really isn't advised to do so, as your opening up the possibility of damage to your system by rogue applications.
Regards,Jason Bourhill
0
