I am seeing a strange behavior with Autodesk AutoCAD Architecture, which creates two seemingly identically named 'Autodesk' folders in My Documents. If you click on them they each contain very different things.

However, Get-ChildItem 'C:\Users\USERNAME\Documents' | ?{ $_.PSIsContainer } | Select-Object FullName returns just a single folder name. Properties of both claim they are folders, and with very different content. Remove-Item 'C:\Users\Px_User\Documents\Autodesk' -recurse will delete one of them, but the second attempt fails, claiming the folder is not there. 

My guess is that there is something jacked up in the permissions. Autodesk is well know for screwing this kind of thing up. But I am trying to figure out, what, if anything, can I even do? If the user doesn't have admin rights, then nothing scripted can be used to delete this junk folder, that of course gets left behind when ACAD is uninstalled because Windows/Autodesk uninstallers are total junk. So very frustrating how much crap gets left behind.

Hmm, I thought Mount Points looked like drive letters, not folders. I found 

Get-WmiObject Win32_Volume | Format-Table Name, Label, FreeSpace, Capacity

And it is returning

None of which seem to have anything to do with a path like C:\Users\Px_User\Documents\Autodesk. Is there any way to manually verify in the properties via Windows Explorer what this thing is?

I don't care why Autodesk did what they did, I just want to delete it. So like I said. I want to use PowerShell to isolate the problem (What IS this thing). Then I want to use PowerShell to solve the problem (Delete this thing). So unless there is some rule that says I can't ask the question, I'll let it stand.

Why do you think PowerShell can do this.  Why not just use the Explorer to delete it?  Yyo have not explained what it is or howit got crested.  What dooes it look like when you do a DIR on it?

It is also possible that your directory structure is corrupt. owerShell cannot help with that.

I should also note that Windows is full of JUNCTIONS that go nowhere and cannot be displayed in PowerShell.  They should not be deleted.  If you look at "My Documents" you will see that it is inaccessible by normal means but is, in fact, a JUNCTION (hard link) to the "Documents" folder.  You cannot display or delete this in PowerShell. It has a special purpose in Windows.

AutoDesk has a reason for creating the hard link.  It shoul not be mmessed with without intructions from AutoDesk.

If you want to dispaly and remove hardlinksyou will need to use tools other than PowerShell.

Because I need it automated obviously. But ok, I'll bite. I am deleting Autodesk's software. With PowerShell. I want to clean up all the crap that gets left behind. This is created by the AutoCAD install, but it gets left behind by the uninstall. So I want to, with PowerShell, delete this, whatever it is. Now, maybe PowerShell CAN'T do this. But I am pretty sure it can, and until we know what the thing is exactly and why it behaves as it does, I don't think there is certainty about what PowerShell can or can't do with it. The directory structure is not corrupt. This is a normal, if pisspour, result of an AutoCAD Architecture install. 

I have dug around some more and it looks like there may be something going on with permissions. The object has some odd permissions assigned, which are not inherited. Also, I can directly access all the files and folders within the object, with PowerShell. It is just the object itself that appears invisible to PowerShell. And which has the exact same name as a folder that is accessible to PowerShell.

Scott Hanselman has produced a workaround for PS to allow viewing or junctions and reparess points:

http://www.hanselman.com/blog/MakingJunctionsReparsePointsVisibleInPowerShell.aspx

This will find all reparse points.

dir -dir -for |?{$_.Attributes -match 'ReparsePoint'}

James is right, this is not a particularly scripting question. I would categorize it as an NTFS file system question (I'm assuming this is on an NTFS formatted volume). 

At any rate, Powershell cmdlets and tools may not show you everything that's on disk. There are several reasons for that. Mainly 2 groups of reasons:

1) PS is .NET based, it runs and uses .NET objects and classes in the background. Many legacy apps and systems use COM and older technologies that .NET may not fully work with

2) NTFS file system issues, details, and exceptions

A typical NTFS volume will have properties like:

Max Component Length : 255
File System Name : NTFS
Is ReadWrite
Supports Case-sensitive filenames
Preserves Case of filenames
Supports Unicode in filenames
Preserves & Enforces ACL's
Supports file-based Compression
Supports Disk Quotas
Supports Sparse files
Supports Reparse Points
Supports Object Identifiers
Supports Encrypted File System
Supports Named Streams
Supports Transactions
Supports Hard Links
Supports Extended Attributes
Supports Open By FileID
Supports USN Journal

For example, take NTFS junction points (AKA directory hard link). Its simply a pointer to a directory/volume/partition. This will show up in the system GUI tools, command line tools, and via PS comdlets. But each set of tools will handle it differently depending on its capabilities.

$MountPoint = "C:\mount"
$ISO = 'Y:\Install\ISO\Server2012R2\WS2012_r2_with_update_x64_dvd_4065220.iso'
$Image = Mount-DiskImage -ImagePath $ISO -NoDriveLetter -PassThru
$Drive = Get-WmiObject win32_volume -Filter "Label = '$($Vol.FileSystemLabel)'" -ErrorAction Stop
if (-not (Test-Path -Path $MountPoint)) { New-Item -Path $MountPoint -ItemType Directory -Force }
$Drive.AddMountPoint($MountPoint)
$Drive.Put()
Get-Volume | FT -AutoSize

This short script illustrates creating an NTFS junction point via PS. In other words, it mounts an ISO file as c:\mount folder instead of mounting it as a drive letter as you might usually do. This has the practical benefit of overcoming the 26 drive letter limitation for example. This could easily mount a VHD(x) disk from a local or remote system as well. As a matter of fact Failover Clustering CSVs (Cluster Shared Volumes) use the same exact technique to mount shared volumes on Hyper-V hosts - typically under c:\ClusterStorage folder. So you could have a c: drive that's 50GB with one ore more mount points that are several TBs each. This may lead to inconsistent results when getting drive space total/free information depending on what tool/method you use to monitor disk space. 

The icon in this examples, gives a clue to the untrained eye that this is not a typical folder. But icons can be changed, and are different by default on different operating systems (this test is on Windows 8.1) 

Now, to show you how different tools will work differently with NTFS features like junction points, try to delete that mount point we just created with PS, like:

Remove-Item c:\mount -Force

That will fail. 

However you can delete c:\mount in Windows Explorer. That will not delete the ISO file of course, it will simply remove the mount point.

Going back to Powershell, Get-Volume will STILL show this phantom volume, even in a new PS session. It only goes away after a reboot..

Long story short, this is mainly an NTFS question. The vendor documentation may be most helpful here. In most cases GUI tools like Windows Explorer will provide more functionality than Powershell.

This is the kind of thing that has nothing at all to do with scripting or this forum. This is a vendor specific issue that need to be posted in the vendor's forum - but you already knew that.

This will find all reparse points.

dir -dir -for |?{$_.Attributes -match 'ReparsePoint'}

Sam, thanks for that! 

I should also mention that going to the vendor here is useless. In all likelihood Autodesk doesn't even know what they have done or why. Certainly no one in their support channel will know, and getting someone in engineering to answer a question like this is brutal. So, I am forced to try and grok for myself what they have done so that I can reverse it when uninstalling the software. And now I have a weekend's worth of new toys to play with tracking it down!

I have worked with AD and had no issues with technical questions. They have alwasy been anxious to help their customers.  I am surprised that you have had a bad experience.

Sam has a good example on mount points.  They shouldn't bedeleted. The volume shoud bedismounted however allremovable vloumes are rememmberd be Windows  There are utilites that will allow youto selectively delete the old ones.

Autodesk does what MS does.  It creates junction with hteolder folder nammes that pointat the newer folder(s) depending on which produces are installed.  I belive these are created the first time you run an AD product.  I do not remember that they are protected. The icrosft symlinks are protected and cannot be easily deleted.  They are necessary too support older software that has hard coded thefolder paths.  MS will remove them  eventually after everyone learns out how to use the required folder protocols.

The way MS protects these sylinks is to set the EveryOne group to deny all access. Remmove everyone from theermissions and you can delete the nks with any tool.

Autodesk has published instructions for removing the products that are quite detailed.

http://knowledge.autodesk.com/customer-service/installation-activation-licensing/get-ready/remove-products/remove-windows-products

Autodesk also has scripts that fully automate the full uninstall including cleaning up the folders and links.

http://knowledge.autodesk.com/search-result/caas/sfdcarticles/sfdcarticles/2011-How-to-perform-an-automated-uninstallation-of-AutoCAD.html

When you have OS issues withAD you must tellthe support people that you want systemm support and not product support.  The product people know how to use the product but are lame on the OS unless you luck into a sharp tech.

I am looking for a PowerShell answer to a Microsoft configuration problem. How is that not appropriate to the scripting forums? I also suspect that it is through scripting tools that I will track down the specifics of the problem that I then need to solve, using PowerShell. Even the data quoted above came from, PowerShell.

• Edited by ThisPublicIdentityIsMine Saturday, January 31, 2015 2:51 AM

It seems to me that you have an AutoDesk configration problem.

Wishful thinking does not make this forum a general purpose technical support forum for broken systems.  I highly recommend contacting AutoDesk or Microsoft support.

There are many reasons why an extra mount point would be created.  The software vendor would be more likely to be able to tell you why.