A search didn't quickly turn up a topic like this... I was using a semi-ancient version of TCC and am now using: TCC 20.00.14 x64 Windows 10 [Version 6.3.14393] TCC Build 14 Windows 10 Build 14393 I don't recall having had problems with %@sfn in the past, but I'm seeing some now. Example: c:\> echo %@sfn["Program Files"] (result:) C:\PROGRA~1 (expected) c:\> echo %@sfn[%programfiles] (result:) C:\PROGRA~1 I made a "Program Files" directory on D: as well. d:\> echo %@sfn["Program Files"] (result:) D:\Program Files (unexpected) c:\> set zorch=D:\Program Files c:\> echo %@sfn[%zorch] (result:) D:\Program Files Now change the "D:" to "C:" in the variable: d:\> set zorch=C:\Program Files Now . . . d:\> echo %@sfn[%zorch] (result:) C:\PROGRA~1 So the @SFN function doesn't seem to work at all with file or directory names on this laptop's D: drive. I noticed this when I upgraded from the semi-ancient TCC version to v.19 and noticed it again on installing v.20 today. I don't recall that sort of thing being a problem in the past. Is it WAD? If so, what's the basis for the difference? And if so, is there some other way to return short filenames on D: without having to resort to using a cmd.exe-style "for" loop? (UGH) I also notice that whereas Control+A toggles between SFNs and LFNs on drive C:, it doesn't work on drive D.