Potential Bug: Shadow Folders and Folder Rename

[CoffeeNerd]

Hello,

We ran into a potential bug today, maybe we just have a setting wrong, where renaming a folder from the GUI client will trip the Shadow Folder service to delete the existing folder, as it should, however the shadow folder service does not build out the folder again with the new name. There were no errors in the Shadow Folder Service log file and the server log file (debug log is turned on) indicates a successful completion to the rename transaction.

After waiting more than enough time (half a day) we used the Web Admin to change the shadow folder setting "speed optimized" from true to false to true again in order to force an update of the shadow folder against the current repository data and once that completed the folder, with its new name, and its contents appeared in the shadow folder; this should have just happened on its own though. We have only one configured and active Shadow Folder set up.

It might also be a nice feature to have a button to force a re-sync of the shadow folder against the repository vs. the messing around with of settings for the shadow folder in question.

Server and Client are running Vault Standard 5.1.1.19215
Server OS is Windows Server 2008 R2 w/IIS 7
SQL DB is SQL Server 2005 Standard w/SP2

Here are the steps to reproduce:

1. Create a subdirectory below some existing directory in Vault and name it foo
2. Create a file in foo on the local filesystem and name it bar and then add it to the repository via the GUI client
3. Make sure the shadowing worked as expected (basically make sure the shadow folders and files were created)
4. Rename the sub-folder from foo to boo in the GUI client and make sure there are no lingering changes in the Pending Change Set window relevant to this change.
5. Check out the shadow…did the rename work? For us foo was gone but boo did not show up to take its place.

Thank you very much!

[Beth]

I'm running a few tests to check this out. Thank you for reporting it.