Short filename bug %%~s

[foxidrive]

This "=%line:~36,12%" part seems to on all systems with default short date format (TT.MM.JJJJ), but if other date formats are in use (for example "T.M.JJ" or "TTTT, TT.MM.JJJJ") it may slides to the left or right.

Thanks, I guess that is another damper on my method.

for %%a in ("%filename%") do set "sfile=%%~sdpnxa"

This would be perfect, but for many many years the short path\filename feature of %%~s has a bug where in certain cases the path\filename is corrupted as a segment of the string is added to the end.

[foxidrive]

I think that temporarily renaming the commas in a file/or the file itself, and renaming it back later, would work - but that might alter the last modified date. I'll check.

EDIT: It works and doesn't alter the last modified date.


The other hurdle is commas in the path, as WMIC requires the full path.

[penpen]

This would be perfect, but for many many years the short path\filename feature of %%~s has a bug where in certain cases the path\filename is corrupted as a segment of the string is added to the end.

I have found what is (still) causing the bug (on my xp home...):
http://stackoverflow.com/questions/8354305/batch-parameter-s1-gives-incorrect-8-3-short-name
I will test, if there are other characters, too, that may trigger the bug.

Wrong, see edit:
The good thing is, it seems that you can use:

Code: Select all

for %%a in ("%filename%") do set "sfile=%%~sdpa"

Only names and extensions are buggy (no matter if single used, or in combination).

penpen

Edit: Oh no... something has triggered the error, and now all pathes are incorrect and the filenames are correct... .

[foxidrive]

I have found what is (still) causing the bug (on my xp home...):
http://stackoverflow.com/questions/8354305/batch-parameter-s1-gives-incorrect-8-3-short-name
I will test, if there are other characters, too, that may trigger the bug.

Edit: Oh no... something has triggered the error, and now all pathes are incorrect and the filenames are correct... .

It looks like the bug is fixed in Windows 8.1 at least.

See this thread I started on Usenet a decade ago: https://groups.google.com/forum/#!topic ... kUsCQuL_bg

This was my test case in the initial post and the problem is gone in Windows 8.1 - at least with this test case.

Code: Select all

@echo off
md "tempfolder with a long name"
cd "tempfolder with a long name"
type nul>"0=3=biz.jpg"
:: type nul>"0 test.jpg"
echo Short name (with bug) and longname
call :test
echo.
echo.running command.com
command /c rem
echo.exiting from command.com
echo.
echo Short name corrected and longname (with path bug)
call :test
cd ..
echo.
pause
rd /s /q "tempfolder with a long name"
goto :EOF
:test
for %%a in (0*.*) do echo %%~sa &echo %%~fa

[foxidrive]

I tried the test case above using a Vista VM and the short filename bug looks like it was fixed in Vista.

[penpen]

For xp you may use the workaround here: http://www.dostips.com/forum/viewtopic.php?p=32053#p32053

penpen

Edit: Updated the link to a better workaround.

[foxidrive]

This is jeb's code to demonstrate the flaw in the short filename bug, as I was alerted that my test case didn't show the bug on one XP machine.

Code: Select all

@echo off
setlocal EnableDelayedExpansion
set myDir=
set myFile=a[1].bat
set map=123456789ABCDEFGHIJKLMNOPQRSTUVW

for /L %%n in (0 1 26) do (
  set "myDir=!myDir!!map:~%%n,1!"
  md !myDir!
  echo dummy > "!myDir!\!myFile!"
  echo Dir=!myDir!
  for %%X in ("!myDir!\!myFile!") do echo   %%~sX
  echo(
  del "!myDir!\!myFile!" > nul
  rd !myDir!

pause
)

[Liviu]

It looks like the bug is fixed in Windows 8.1 at least.

Just curious, and don't have 8.1 handy now, but was the _other_ %%~s bug viewtopic.php?p=23974#p23974 fixed, too?

Liviu

[foxidrive]

Can you provide a batch file to demonstrate the issue, please?

Something that creates the folder structure and shows the issue?

[Liviu]

It's a bit difficult to create the folder structure in a batch file, since the issue only shows when using names with Unicode characters - which can't be reliably hardcoded in a batch file.

However, it's fairly easy to duplicate it at the cmd prompt. Below is a minimal example taken from my previous post, copied from a Win7x64.sp1 cmd prompt (set to Lucida Console font, assuming an initially empty C:\tmp, and with some irrelevant 'dir' lines stripped)...

Code: Select all

C:\tmp>ver

Microsoft Windows [Version 6.1.7601]

C:\tmp>md "20                 €"

C:\tmp>dir /ad /x

02/06/2014  03:41 PM    <DIR>          202075~1     20                 €

C:\tmp>copy nul "20                 €\12345=7.1"
        1 file(s) copied.

C:\tmp>dir /x "20                 €"

02/06/2014  03:41 PM                 0 12345_~1.1   12345=7.1

C:\tmp>for /R %k in (*) do @if not exist "%~sk" echo "%~sk" ---???--- "%~fk"
"C:\tmp\202075~1\12345_~1.1 \12345=7.1" ---???--- "C:\tmp\20                 €\12345=7.1"

C:\tmp>

The echo'd line shows a wrong %~sk being returned.

[foxidrive]

Code: Select all

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

d:\tmp>md "20                 €"

d:\tmp>dir /ad /x

07/02/2014  13:38    <DIR>          202075~1     20                 €

d:\tmp>copy nul "20                 €\12345=7.1"
        1 file(s) copied.

d:\tmp>dir /x "20                 €"

07/02/2014  13:39                 0 12345_~1.1   12345=7.1

d:\tmp>for /R %k in (*) do @if not exist "%~sk" echo "%~sk" ---???--- "%~fk"
"d:\tmp\202075~1\12345_~1.1 \12345=7.1" ---???--- "d:\tmp\20                 €\12345=7.1"

d:\tmp>chcp
Active code page: 850

In the short path name there is an unprintable character after "d:\tmp\202075~1\12345_~1.1 and before the \

[Liviu]

Thanks. So this %%~s bug is _still_ not fixed in 8.x. That's Windows taking backwards compatibility to extremes

In the short path name there is an unprintable character after "d:\tmp\202075~1\12345_~1.1 and before the \

Must be the same U+2000 "en quad" character as under win7 (which can be verified by replacing 'echo' with 'cmd /u /c echo ^>tempfile', and inspecting the hex contents of the saved file). It's only present in the %~sk expansion, not in the actual SFN, or the dir /x output.