dir sed*.* /s

  • Thread starter Thread starter Jim Carlock
  • Start date Start date
J

Jim Carlock

First, I know this is not a Visual Basic question. And I do not
even know if this limited to only one machine. But I expected
the above to list files like sed.exe, sed342.exe, sed.txt and
so on. However, I ended up with some very odd results. I don't
think I've ever seen the "dir" command behave this way. I did
not see an XP cmd group and the Win2K cmd group does not seem
to get much attention.

C:\test\>dir sed*.* /s

When I typed that into a cmd.exe prompt on XP SP2, the following
were identified as matching files:

04/18/2004 06:00 PM 2,176 SetStaticByteField_3.cpp
04/18/2004 06:00 PM 2,158 SetStaticByteField_4.cpp
04/18/2004 06:00 PM 2,157 SetStaticByteField_1.cpp
04/18/2004 06:00 PM 2,178 SetStaticByteField_2.cpp

11/27/2001 03:59 PM 234 server-news-lock.gif
02/21/2004 04:16 PM 370 server-remote-lock-new.gif

Wondering if someone can duplicate that on Win2K or other versions
of XP?

Thank you for your time.
 
First, I know this is not a Visual Basic question. And I do not
even know if this limited to only one machine. But I expected
the above to list files like sed.exe, sed342.exe, sed.txt and
so on. However, I ended up with some very odd results. I don't
think I've ever seen the "dir" command behave this way. I did
not see an XP cmd group and the Win2K cmd group does not seem
to get much attention.

C:\test\>dir sed*.* /s

When I typed that into a cmd.exe prompt on XP SP2, the following
were identified as matching files:

04/18/2004 06:00 PM 2,176 SetStaticByteField_3.cpp
04/18/2004 06:00 PM 2,158 SetStaticByteField_4.cpp
04/18/2004 06:00 PM 2,157 SetStaticByteField_1.cpp
04/18/2004 06:00 PM 2,178 SetStaticByteField_2.cpp

11/27/2001 03:59 PM 234 server-news-lock.gif
02/21/2004 04:16 PM 370 server-remote-lock-new.gif

Wondering if someone can duplicate that on Win2K or other versions
of XP?

Thank you for your time.
Click to expand...

More than likely the short (8.3) name starts with sed. I forgot what switch
you add to see that. /x?
 
Jim Carlock said:
First, I know this is not a Visual Basic question. And I do not
even know if this limited to only one machine. But I expected
the above to list files like sed.exe, sed342.exe, sed.txt and
so on. However, I ended up with some very odd results. I don't
think I've ever seen the "dir" command behave this way. I did
not see an XP cmd group and the Win2K cmd group does not seem
to get much attention.

C:\test\>dir sed*.* /s

When I typed that into a cmd.exe prompt on XP SP2, the following
were identified as matching files:

04/18/2004 06:00 PM 2,176 SetStaticByteField_3.cpp
04/18/2004 06:00 PM 2,158 SetStaticByteField_4.cpp
04/18/2004 06:00 PM 2,157 SetStaticByteField_1.cpp
04/18/2004 06:00 PM 2,178 SetStaticByteField_2.cpp

11/27/2001 03:59 PM 234 server-news-lock.gif
02/21/2004 04:16 PM 370 server-remote-lock-new.gif

Wondering if someone can duplicate that on Win2K or other versions
of XP?

Thank you for your time.
Click to expand...

As Jeff suggested, this happens because your SFNs start with "SED".
You will see this phenomenon when you have many files in the same
folders, forcing the SFN algorithm to go through lots of permutations.

You can avoid the problem by turning off SFN creation:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem value
NtfsDisable8dot3NameCreation
 
Jim Carlock said:
First, I know this is not a Visual Basic question. And I do not
even know if this limited to only one machine. But I expected
the above to list files like sed.exe, sed342.exe, sed.txt and
so on. However, I ended up with some very odd results. I don't
think I've ever seen the "dir" command behave this way. I did
not see an XP cmd group and the Win2K cmd group does not seem
to get much attention.

C:\test\>dir sed*.* /s

When I typed that into a cmd.exe prompt on XP SP2, the following
were identified as matching files:

04/18/2004 06:00 PM 2,176 SetStaticByteField_3.cpp
04/18/2004 06:00 PM 2,158 SetStaticByteField_4.cpp
04/18/2004 06:00 PM 2,157 SetStaticByteField_1.cpp
04/18/2004 06:00 PM 2,178 SetStaticByteField_2.cpp

11/27/2001 03:59 PM 234 server-news-lock.gif
02/21/2004 04:16 PM 370 server-remote-lock-new.gif

Wondering if someone can duplicate that on Win2K or other versions
of XP?

Thank you for your time.
Click to expand...

If you're looking for an XP-oriented batch group, try alt.msdos.batch.nt -
or alt.msdos.batch (both are about the same nowadays...)

As for the problem - almost certainly finding short filenames. The short
filename seems to preserve the first two characters only reasonably
reliably. What follows id Hobson's choice - especially after the fourth
"reasonably similar" filename.

DIR /S will show the short-filename.
 
billious said:
If you're looking for an XP-oriented batch group, try alt.msdos.batch.nt -
or alt.msdos.batch (both are about the same nowadays...)

As for the problem - almost certainly finding short filenames. The short
filename seems to preserve the first two characters only reasonably
reliably. What follows id Hobson's choice - especially after the fourth
"reasonably similar" filename.

DIR /S will show the short-filename.
Click to expand...

I wonder why you bothered to answer. The short file name issue
was already covered by two previous respondents (to whom you
failed to give credit), and your own contributions were by and
large incorrect: Win2000.cmdprompt.admin IS an appropriate
newsgroup for asking questions about console commands, and
the /s switch, as Jeff pointed out, will not show the short file name.
 
Pegasus (MVP) said:
As Jeff suggested, this happens because your SFNs start with "SED".
You will see this phenomenon when you have many files in the same
folders, forcing the SFN algorithm to go through lots of permutations.

You can avoid the problem by turning off SFN creation:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem value
NtfsDisable8dot3NameCreation
Click to expand...

REG_DWORD value named NtfsDisable8dot3NameCreation with a value set to
0 or 1 the appropriate fix. It appears that the system needs a reboot
to activate this. Can anyone confirm a VB (or other code which might
get translated) way to force a registry reloading (I'm thinking the
quick suggestions might involve a logoff or some sort of automated
reboot). Just wondering if there's a way to get this done without doing
the logoff and/or reboot.

Thanks, Pegasus and Jeff. I looked for a switch to place in the
DIRCMD EV. Such a shame to not have one.

Thanks to 'billious' for suggesting other newsgroups (alt.msdos.batch
and alt.msdos.batch.nt).
 
JC said:
REG_DWORD value named NtfsDisable8dot3NameCreation with a value set to
0 or 1 the appropriate fix.
Click to expand...

That's a pretty drastic "fix" that may interfere with operations on some
systems that expect or need the 8.3 names. It'd be better IMO to check the
results and skip any that don't match what you want.
 
Monitor said:
I wonder why you bothered to answer. The short file name issue
was already covered by two previous respondents (to whom you
failed to give credit), and your own contributions were by and
large incorrect: Win2000.cmdprompt.admin IS an appropriate
newsgroup for asking questions about console commands, and
the /s switch, as Jeff pointed out, will not show the short file name.
Click to expand...

You seem to misunderstand the nature of the internet.

Simply because a post is made at a particular time does not mean that it is
visible at that time to everyone. There were no responses visible to me when
I replied.

win2000etc is an appropriate but ill-frequented group. The groups that I
mentioned are far more active - even if they don't have the magic
"microsoft" or "cmdprompt" as part of their names. Further, it was extra
information, seeing as neither of the other respondents whose responses I
hadn't seen hadn't mentioned them.

Certainly, the /S switch was a typo and should have been /X. Mea culpa. I
also typed "id" in place of "is." Mea maxima culpa.

But what else about what I said was "incorrect?"

The newsgroups?
That alt.msdos.batch and alt.msdos.batch.nt are about the same nowadays?
(See 'on-topic policy' comments of 22/8/08 in both groups)
Generation of short filenames? Well - that's based on empirical data. Try

for /l %i in (1,1,8) do dir>"this is a long filename%i.txt"

which should generate 8 filenames which will be "reasonably similar." On my
machine, here's the result of a dir/x :

06/08/08 01:41 4,355 THISIS~1.TXT this is a long filename1.txt
06/08/08 01:41 4,419 THISIS~2.TXT this is a long filename2.txt
06/08/08 01:41 4,483 THISIS~3.TXT this is a long filename3.txt
06/08/08 01:41 4,547 THISIS~4.TXT this is a long filename4.txt
06/08/08 01:41 4,611 TH18C2~1.TXT this is a long filename5.txt
06/08/08 01:41 4,675 TH18C6~1.TXT this is a long filename6.txt
06/08/08 01:41 4,739 TH28CA~1.TXT this is a long filename7.txt
06/08/08 01:41 4,803 TH28CE~1.TXT this is a long filename8.txt

Which, I believe, proves the point. The short filename retains the first 2
characters from the lfn in each case. For the first 4, the filename is the
first 6 non-space characters then a tilda and the sequence 1,2,3,4 - the
extent (or "secondary filename" if you're old enough to recognise that
terminology) is retained.
After the first four, the first two characters are followed by what is
apparently a hex code then ~1.

Or are you saying that DIR would not incorrectly report on the short
filenames?

So - what about my claims is "incorrect?"

And then I'll put the question back to you - why did you bother responding,
since you had nothing positive to contribute, only largely-incorrect
criticism and to repeat the indication of the error that you acknowledge had
already been detected?
 
"Pegasus (MVP)" suggested:
"JC" suggested in return...
REG_DWORD value named NtfsDisable8dot3NameCreation with a value set to
0 or 1 the appropriate fix.
Click to expand...

...
: That's a pretty drastic "fix" that may interfere with operations on
: some systems that expect or need the 8.3 names. It'd be better IMO
: to check the results and skip any that don't match what you want.

Well, the verdict is in. It did NOT fix the problem. I rebooted the
system, confirmed the key was in place, as a DWORD value set to 1.

There's something more going on other than just that one key in the
registry. The hard disk drive is NTFS formatted, so perhaps the the
"Master" (?) file table does not adjust itself based upon that key.

Something else must be done, perhaps reformatting the drive? Yikes.
I'll defrag the drive tonight and see if that corrects it. Unless
someone else has another suggestion, I'm going to just forget about
the trouble for the time being. The proper thing would be to write
a VB application to find the files and then forget about the cmd
prompt. Someone else probably already wrote a file finding cmd-line
tool (maybe in unxutils). ls.exe seems to work properly and lists
file contents with sed*.* in it as well. It just is not listing the
folders in which they're located in.

C:\>ls.exe -R sed*.*

sed.exe sed414.chm sed414.exe sed414.hlp

sed=:
readme.txt sed.cmd sed.scr test.txt

C:\>
 
JC said:
"Pegasus (MVP)" suggested:

"JC" suggested in return...

...
: That's a pretty drastic "fix" that may interfere with operations on
: some systems that expect or need the 8.3 names. It'd be better IMO
: to check the results and skip any that don't match what you want.

Well, the verdict is in. It did NOT fix the problem. I rebooted the
system, confirmed the key was in place, as a DWORD value set to 1.

There's something more going on other than just that one key in the
registry. The hard disk drive is NTFS formatted, so perhaps the the
"Master" (?) file table does not adjust itself based upon that key.
Click to expand...

That value disables "8dot3NameCreation" with the emphasis on "Creation". As
far as I know any existing 8.3 names are untouched.
 
Well, the verdict is in. It did NOT fix the problem. I rebooted the
system, confirmed the key was in place, as a DWORD value set to 1.
Click to expand...

Note the name of the registry key: "Creation." I believe that short files
names which have ALREADY been created are not deleted, and so this only
applies to files created from that point on.
 
First, I know this is not a Visual Basic question. And I do not
even know if this limited to only one machine. But I expected
the above to list files like sed.exe, sed342.exe, sed.txt and
so on. However, I ended up with some very odd results. I don't
think I've ever seen the "dir" command behave this way. I did
not see an XP cmd group and the Win2K cmd group does not seem
to get much attention.

C:\test\>dir sed*.* /s

When I typed that into a cmd.exe prompt on XP SP2, the following
were identified as matching files:

04/18/2004 06:00 PM 2,176 SetStaticByteField_3.cpp
04/18/2004 06:00 PM 2,158 SetStaticByteField_4.cpp
04/18/2004 06:00 PM 2,157 SetStaticByteField_1.cpp
04/18/2004 06:00 PM 2,178 SetStaticByteField_2.cpp

11/27/2001 03:59 PM 234 server-news-lock.gif
02/21/2004 04:16 PM 370 server-remote-lock-new.gif
Click to expand...

This is a workaround to find the filenames of interest, and path:

Launch it like this, no *.* is needed: batchfile.bat sed

@echo off
for /f "delims=" %%a in ('dir /s /b /a-d^|find /i "\%1"') do (
echo "|%%~nxa"|find /i "|%1">nul&&echo "%%a"
)
 
This is a workaround to find the filenames of interest, and path:
Launch it like this, no *.* is needed: batchfile.bat sed

@echo off
for /f "delims=" %%a in ('dir /s /b /a-d^|find /i "\%1"') do (
echo "|%%~nxa"|find /i "|%1">nul&&echo "%%a"
)
Click to expand...

Many, many, many, many years ago, I used to be able to write batch code like
that. Apparently I have forgotten a lot of what I used to know as half of
your posted batch code looks like gobbledygook to me now.<g>

Rick
 
Rick Rothstein (MVP - VB) said:
Many, many, many, many years ago, I used to be able to write batch code like
that. Apparently I have forgotten a lot of what I used to know as half of
your posted batch code looks like gobbledygook to me now.<g>

Rick
Click to expand...

LOL

I had exactly the same reaction.
[I know I had a book around here somewhere ... ]

-ralph
 
Ralph said:
Rick Rothstein (MVP - VB) said:
Many, many, many, many years ago, I used to be able to write batch code like
that. Apparently I have forgotten a lot of what I used to know as half of
your posted batch code looks like gobbledygook to me now.<g>

Rick
Click to expand...

LOL

I had exactly the same reaction.
[I know I had a book around here somewhere ... ]
Click to expand...

Many, many, many, many years ago, I used to be able to write text like that.
Apparently I have forgotten a lot of what I used to know as all of your post
looks like gobbledygook to me now.

/Al ;-)
 
Back
Top