Thanks for the speedy response Xavier.
Alas, in my tests here (Windows 10 Pro v1903 build 18362.592), the fail rate is a 100%, not a 1%
I did a bit of digging and, you've guessed it - Windows DOS style commands are no longer a given thing, and
del is one of those that no longer behaves properly, or like it used to. There is a fair amount of chat about this if you look around on the net, but it's not something that is all that obvious unless you seek it out. Simply put,
del doesn't even work according to its own specified help-text anymore.
The reason the Transfer folder won't be deleted is because it (understandably) still contains files in its Assets and Content folders and because the batch merely calls for
del /q Transfer and isn't explicitly told to deal with sub-folders, it fails to get everything.
del won't delete file from sub-folders unless it is commanded to:
del /s is the method for that.
del /s /q Transfer would, in theory, work - but
del isn't really intended to delete folders, just
files. It won't remove the tree of empty folders left behind once all the contained files are gone, annoyingly.
To remove the tree of skeleton folders, you'd use
rmdir - which is intended to handle folder deletion. Again, sub-folders are required to be explicitly mentioned, so
rmdir /s /q Transfer is the 'standard' invocation for removing an empty folder tree.
Except that Windows being Windoze, even this will not work 100% reliably for reasons only known to Microsoft. Sometimes even
rmdir fails, complaining that a folder still has files in it, even when it is quite clearly empty. IMHO this has something to do with DOS command-prompt running in 'virtual mode' interacting with the OS's in-built Windows Explorer, and one not quite catching up with the other - a timing issue, while others have said it is something to do with whether Search Indexing is enabled on the drive, or hard-drive corruption, or virus-scanners in use (but the results are inconsistent, so I'm not convinced) - but that's all for MS to resolve, not us (assuming they've not just given up with DOS in favour of PowerShell instead). We just have to work (or workaround) with the now-broken tools, I guess. (some more insights - and nonsense - here, if you're interested:
stackoverflow.com/questions/22948189/batch-getting-the-directory-is-not-empty-on-rmdir-command )
The solution, ugly though it is, is to use a loop on the
rmdir and keep hammering it, until the folders are definitely gone. Such as this:
:transfer_remover_loop
del /s /q "Transfer"
rmdir /s /q "Transfer"
if exist "Transfer" goto transfer_remover_loopTechnically, the del part should only need running once, and could be put above the label line (
:transfer_remover) but it won't hurt to leave it in the loop. Leaving it here will catch any possible
del fails as well as any
rmdir fails. The process will continue around the loop until
Transfer no longer exists, at which point it will carry on.
If the fear of getting trapped in the batchfile forever worries you, you could always use
set /a x=0 just before the entry to the loop to initialise a counter variable, and then use a
set /a x+=1 and an test of the philosophy to create a little counter variable for incrementing and testing and escape if it went on looping for too long.
Similarly, if you wanted to hide the big output of the file-copies and deletions appearing in the DOS window, you could pipe the output of the
xcopy,
del and
rmdir commands that you're using to
> nul to hide them from the user completely and/or just print what you wanted them to see (
echo: "All is well... this house is clean!" LOL)
Here's a slightly more advanced version (just to handle the deletion of
Transfer folder), coping with those concepts:
@echo off
set /a loopcount=0
echo Removing installer temporary files
:transfer_remover_loop
set /A loopcount += 1
if "%loopcount%" == "10" (
goto transfer_complete
) else (
echo Attempt %loopcount%
del /s /q "Transfer" >nul
rmdir /s /q "Transfer" >nul
if not exist "Transfer" (
goto transfer_complete
) else (
goto transfer_remover_loop
)
)
:transfer_complete
echo Installer temporary files removedN.B. There is technically still a chance that if the
rmdir bit encounters a read-only file or folder, then it may barf (silently, because of the
/q) - but in theory, there shouldn't ever be any read-only files in these folders. If you're worried about that, use the /f option on the del and the rmdir sequences - but imho, it's unlikely.
Similarly, I haven't found a way of suppressing the output from the
if not exist bit (due to the presence of a multi-line block following), so the user will see a message along the lines of:
Could Not Find Z:\Transfer
The system cannot find the file specified.but this can safely be ignored, and even referred to in the following
echo line(s) to make it clear it has definitely worked!
You should also be aware that (once this is all working)
it will start deleting any user-made homegrown files that they have been daft enough to leave anywhere in the VDL Routes or Scenarios folder (e.g. if they have cloned scenarios, but not the route itself, and 'had a play' with a scenario, then the working version of this batchfile will silently destroy them forever! Might be worth putting a big hint in the startup pages of the installer, and the manual, to take copies of personal files, and best to avoid leaving them in that area in the first place (i.e. clone the whole route, and make your cloned-scenarios there, if you must - then the installer will never touch them).
For ref, it's worth assuming that hitherto, your attempts to delete the folder-trees below
Assets\RScott\LondonTransport and
Assets\Virtual District Team\London Underground District Railway will
probably have failed (if there was pre-existing content there and this was a re-install, or a later version install 'over the top').
The deletes to the old inputmappers in the
Kuju\RailsimulatorCore\Inputmappers folder should have worked, because they are single file calls upon del, and not subject to any of this nonsense (
I saw those deletions, and did wonder if this was a cleanup from a previous-version install error, so it's nice to have the reassurance that it is indeed the case, and thus safe 
)
I hope this is useful to you in some way. Discovering that
Transfer folder did make me think I'd had a senior moment during a backup attempt, and it took me a while to get to the bottom of why it existed. Having discovered why, I felt it only fair payback to see if I could find a solution for you! I have no idea what your incidence rates are of this folder still existing on people's machines, but given that it's 2GB in size, it's probably worth letting them know to look - or at least to be sure of zapping it quietly in any future update.
All the best!
