choco install -y C: deletes all files

[bill-long]

If you run choco install -y C:, all files are deleted from the folder where you ran this command.

In remove_rollback_directory_if_exists(), the packageName being passed in is "C:":

        public void remove_rollback_directory_if_exists(string packageName)
        {
            var rollbackDirectory = _fileSystem.combine_paths(ApplicationParameters.PackageBackupLocation, packageName);

So rollbackDirectory is now set to "C:". Finally we end up in chocolatey.infrastructure.filesystem.DotNetFileSystem.delete_directory(), with a directoryPath of "C:" and recursive set to true. Then we call:

allow_retries(() => Directory.Delete(directoryPath, recursive));

I'm a little surprised this doesn't actually wipe out everything starting from the root of C: in my tests, but it seems that it hits an exception trying to delete the folder where the command is being run. So maybe the exception saves you if you happen to run this from a subfolder with nothing important in it.

Of course, if you actually run this command from the root of C:, then it makes quite a mess of things.

[ferventcoder]

Thanks for investigating the reason @bill-long - this will be something to fix quite quickly!

[ferventcoder]

[ferventcoder]

For posterity, this was discovered based on the LabTech plugin for choco noted https://gitter.im/chocolatey/choco?at=558b84c638e37bf74261d3bd

[ADTC]

That C: points to the current working directory in C drive is a well-known anomaly in MS-DOS and Windows. If you want to refer to the root of C drive, you have to specify C:\

Having that said, I wonder what would have happened if you had done choco install -y C:\ (in the unfixed version).

[ferventcoder]

Note that there may be a fix if you are affected by this: http://www.squidworks.net/2015/06/labtech-chocolatey-nuget-ii-plugin/#comment-17200

From Ben Perkins:

If anyone else runs into this issue, we found a much better fix than reloading everything. Boot the effected machines to a windows 2 go type of portable windows install. Log in as admin. Use Shadow copy and pick a restore date prior too the issue. The only effected directory really seemed to be \Windows as all user data and program data appeared to be intact. After you extract the Shadow copy, copy the Windows directory minus the temp and sys32 folders and skip any of the same files. Then copy the sys32 folder over top of the sys32 folder of the effected machine. This was successful 90% of the time and all that was left were a few domain trust issues.