@abbodi1406 I finally had the chance to test the updated Winsxs lite I attempted to service offline a fully updated (except ESU) Server2012 installation using Server 2012 R2. No luck, for now it starts and close itself almost instantaneously blaming about \Toshiba\Bluetooth as unexpected. I have no time right now to try to bisect the problem but likely it's some virtual path set by the toshiba bluetooth stack that confuses it. (i personally use the Toshiba stack everywhere, but being servers it's almost mandatory to have a fully functional BT stack) I'll try to look on it tomorrow, but if in the meantime you have an idea it's welcome.
@acer-5100 I didn't change the original command that sets Path environment, which doesn't account for paths with spaces or () search for Code: path %home%bin;%PATH% change to Code: set "Path=%home%bin;%PATH%" or download updated WinsxsLite1.90a.7z
Yeah, but I never tried to service 9200 x64 from another x64 system. Whatever... It worked I mean it's scanning and that will take a lot of time because it's running on a slow machine, let see if the logic of the program is still valid in 2023 or if it will destroy the system (It's a native vhdx replaceable with a copy in 5 minutes )
Maybe there is another (minor) glitch In the parent cmd window, there are some errors about scanning some files Like which is really I guess some localization/unicode confusion BTW shouldn't be a problem, given hardly windows own files have odd characters in filenames
@abbodi1406 Yet another small thing. The version check fails on Win10 I changed Code: for /F "delims=." %%a IN ('ver') DO set z=%%a set NoVista= if %z:~-1% LSS 6 set NoVista=true to Code: for /f "tokens=6 delims=[]. " %%G in ('ver') do set winbuild=%%G set NoVista= if %winbuild% LSS 6000 set NoVista=true And seem working
@abbodi1406 @George King Ok, not that in the recent days I had time to do extensive tests, but I can say that phase 1 works as it used, but phase 2 is definitely not safe (it screws the .net installations), definitely it tries to optimize too much (over 7GB of recovered space). I dont think this is a Win8+ problem but rather a problem related to how much .net changed over the last 11 years, so likely phase 2 in 2023 isn't safe even on win7 or vista For now I can say that using dism++ (2GB freed) + SxSlite (another 2GB recovered) worked perfectly on Server 2012, leading to a situation close to what the official resetbase would get. (according to dism++ there were initially about 6GB to cleanup, 2GB were actually cleared, 4GB required the nonexistent resetbase command, so the end of combined dism++ & sxslite Phase 1 result is supposedly just 2GB larger than the optimal one)
@abbodi1406 I found another small problem. SxSlite didn't work at all on an Server 2012 installation, I quickly tracked down the problem... The genius @ toshiba added some path with spaces and no quotes when the bluetooth stack was installed. So I just changed the system path adding the quotes, and the problem was solved. But maybe you have a smarter way to solve the problem from the script side, given possibly other SW may do the same thing
@acer-5100 I had similar issue a lot with my earlier scripts, using %PATH% as-is isn't reliable i would simply replicate the default Path locations instead Code: set "Path=%home%bin;%SystemRoot%\System32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SystemRoot%\System32\WindowsPowerShell\v1.0\"
Yes that was my next try idea, if what I did didn't work. KISS has its own beauty after all, but then I though maybe our scripting king friend has some ready made wizardry that parse the path correctly even in such cases.
Unless the path's paths contain !, i think delayed expansion would work Code: setlocal EnableDelayedExpansion set "Path=%home%bin;!PATH!"
It doesn't seem working, perhaps the delayedepansion is explicitly disabled at the beginning of the script, so there must be a reason for that. Aside that I noticed that the problem isn't there in 32bit OS, so the problem aren't the spaces as I (wrongly) guessed, the problem are the brackets in \Program Files (x86)\ As usual in IT never take anything for granted, triple or more checks to exactly bisect a problem is always a requirement.
I wasn't clear enough. I mean that the script starts this way Code: @setlocal ENABLEEXTENSIONS DISABLEDELAYEDEXPANSION @echo off :: change to 1 to redirect scan progress window output to a text file set LogProgress= I guess this is from the original author, not from you. Hence I think that if he did it it was for a reason, maybe setting DELAYEDEXPANSION will break something later, btw I didn't spend too much time on it given I'm busy with a different thing.