0

In my installer script I want to delete known files from known locations on the local PC using the DEL command. The command should purge the file from a certain folder and all subfolders below that. I therefore use:

cd /d "C:\MyFolder"
del /f /s /q MyFile.xyz

However, if a junction is mapped somewhere below "C:\MyFolder" (say, at "C:\MyFolder\Junction", pointing to another folder on the same drive), DEL doesn't seem to traverse into it at all. So all "MyFile.xyz" files under there will not be deleted. If DEL also cannot find the file anywhere else under the root folder, it'll also happily report "Could Not Find C:\MyFolder\MyFile.xyz".

There doesn't seem to be any switches that control this behavior, nor do command extensions help -- is this a known limitation of DEL?

Are there any workarounds using either commands or standard apps installed by default on fresh contemporary Windows machines, or should I write my own DEL-like executable for this / perform the same action using a script in my installer?

Carl Colijn
  • 101
  • 3

1 Answers1

1

If the junction point is hosted on the network the problem is most probably the installation script need to be runned as a admin.

Running it as an admin make it use local credential, and most junction point point to a network share usually, thus the DEL command lack the credential to navigate the junction point.

yagmoth555
  • 16,300
  • 4
  • 26
  • 48
  • 1
    Thanks for the insight! But this is all on my local machine, no network in sight :) I'll update my post to include this. – Carl Colijn May 19 '22 at 14:25
  • @CarlColijn Thansk for edit. If you run such command; Get-ChildItem -Path "c:\MyFolder" -File -Include MyFile.xyz -Recurse | Remove-Item -Force -Verbose does it work ? if yes I would tend to think like you a del limitation then – yagmoth555 May 19 '22 at 14:31
  • 1
    Yep; that powershell snippet does work, even when ran from outside the junction. So probably a built-in DEL limitation indeed. Problem is I don't think I can convince the guy maintaining the script to start using Powershell :) Luckily this problem is almost only theoretical though (so far we know it only from my dev machine and not from customers). – Carl Colijn May 19 '22 at 14:39