Can I kill off the _sgvault directory on the Vault Server?
Moderator: SourceGear
Can I kill off the _sgvault directory on the Vault Server?
Got a the Vault server running on one machine, the SQL DB on another machine, and a bunch of clients hooked in on other machines.
On the Vault server machine, the application data directory (or at least the /SourceGear/Vault_1/Admin/{random GUID}/admin/_sgvault sub directory) contains a heap of hidden directories (about 100,000), and uses up a fair whack of disk space (about 4Gig).
Can I nuke this directory? The machine this directory is on is just the Vault server - the client is installed but never used for check ins/outs...
All the clients have their own _sgvault directories (mine's only 500 files and 160 Mb, which is cool).
Either way - I'm fast running out of disk space on my Vault server - it's a dedicated machine just for Vault, so there's not much excess crap installed...
This is all in version 2.0.3 - server is a Windows 2K Pro box, SQL Server is Win2k3 Advanced, clients are all XP Pro, .Net Framework version is 1.1
Any ideas?
Matt
On the Vault server machine, the application data directory (or at least the /SourceGear/Vault_1/Admin/{random GUID}/admin/_sgvault sub directory) contains a heap of hidden directories (about 100,000), and uses up a fair whack of disk space (about 4Gig).
Can I nuke this directory? The machine this directory is on is just the Vault server - the client is installed but never used for check ins/outs...
All the clients have their own _sgvault directories (mine's only 500 files and 160 Mb, which is cool).
Either way - I'm fast running out of disk space on my Vault server - it's a dedicated machine just for Vault, so there's not much excess crap installed...
This is all in version 2.0.3 - server is a Windows 2K Pro box, SQL Server is Win2k3 Advanced, clients are all XP Pro, .Net Framework version is 1.1
Any ideas?
Matt
Matt:
The server does not use / create _sgvault directories. These directories would have been created by the Vault Admin tool or the Vault client.
In any case, it is fine to wipe the %APPDATA%\SourceGear\Vault_1\. The next login from the admin tool or client will re-create the info.
Before deleting this, can I ask you to double check the space allocation? Are you certain the space is allocated in %APPDATA%\SourceGear\Vault_1\Admin and not %APPDATA%\SourceGear\Vault_1\Client?
Just curious.
The server does not use / create _sgvault directories. These directories would have been created by the Vault Admin tool or the Vault client.
In any case, it is fine to wipe the %APPDATA%\SourceGear\Vault_1\. The next login from the admin tool or client will re-create the info.
Before deleting this, can I ask you to double check the space allocation? Are you certain the space is allocated in %APPDATA%\SourceGear\Vault_1\Admin and not %APPDATA%\SourceGear\Vault_1\Client?
Just curious.
Jeff Clausius
SourceGear
SourceGear
Dan raises a good point.
Vault's shadow folder will create baselines (_sgvault) in MACHINE_NAME\ASPNET\%APPDATA%\SourceGear\Vault_1\PluginWebService or an impersonated user's %APPDATA%\SourceGear\Vault_1\PluginWebService.
This gets back to my original question - In what directory can you find _sgvault?
Vault's shadow folder will create baselines (_sgvault) in MACHINE_NAME\ASPNET\%APPDATA%\SourceGear\Vault_1\PluginWebService or an impersonated user's %APPDATA%\SourceGear\Vault_1\PluginWebService.
This gets back to my original question - In what directory can you find _sgvault?
Jeff Clausius
SourceGear
SourceGear
Ok - it's definitely the Admin directory, not the Client directory - the client directory has a handful of files and folders below it, but nothing out of the ordinary.
The user in this case is the logged on user "Tester", which does NOT have a Vault login (Tester is a Windows logon only). Could these files be a hangover from the VSS import? It was a pretty substantial VSS db - 2-3Gb (you might even remember me having whinges about the fact that the conversion took close to a month to run )?
I'll log the user off and back on and see what happens.
Matt
The user in this case is the logged on user "Tester", which does NOT have a Vault login (Tester is a Windows logon only). Could these files be a hangover from the VSS import? It was a pretty substantial VSS db - 2-3Gb (you might even remember me having whinges about the fact that the conversion took close to a month to run )?
I'll log the user off and back on and see what happens.
Matt