File management via SFNs

[Charles Dye]

I'm cleaning up one of the file servers this week, and have to cope with numerous files with blatantly illegal filenames. (Damn Mac users.) And to my chagrin, I'm having to use CMD.EXE to fix them.

Take, for instance, "12340_contents.pdf " (that's 82 spaces on the end -- I swear I'm not making this up!) Neither TCC nor CMD.EXE can cope with this, of course. Using CMD.EXE, I can delete the monster using its short filename, 12340_~2.PDF. In TCC, this doesn't work. It appears that TCC thoughtfully converts the SFN back to the corresponding (illegal) long filename, so I either get an error message or else whack the wrong file.

I had thought that turning on Win32SFNSearch would allow using short filenames for file management, but apparently not. Is this the intended behavior? Is there any way to disable this feature (automatically converting SFNs to LFNs behind the scenes)? I can see why it would be desirable 99% of the time, but when it comes to illegal filenames, it can definitely be a Bad Thing (deleting or renaming the wrong file/subdirectory.)


On a different topic, but related to the same cleanup chore: What's the maximum filename length in v12? HELP LIMITATIONS has it at 4K, but I was under the vague (wrong?) impression that that had been increased a major version or two back. (Multi-sentence subdirectory names, nested twelve deep; don't ask me, I don't know.)

 

[Charles Dye]

Take, for instance, "12340_contents.pdf " (that's 82 spaces on the end -- I swear I'm not making this up!)

TCC is great for finding these monstrosities, using a wildspec like "*[ ]". So for now, I'm using a two-shell approach....

 

[Steve Fabian]

Charles Dye:
| Take, for instance, "12340_contents.pdf " that's 82 spaces on the end
TCC is great for finding these monstrosities, using a wildspec like "*[ ]".
So for now, I'm using a two-shell approach....

Did you try
*del /p "*[ ]"

One issue you might have is that even though a filename is LFN, there might
not be an associated SFN, in which case the Win32SFNsearch would not help...
--
Steve

 

[Charles Dye]

Did you try
*del /p "*[ ]"

Yup. TCC does find the offending files, but fails to delete them, doubtless because the filename it's passing to DeleteFile() is in fact invalid.... DEL * doesn't delete them either. (Oddly enough, DEL * in CMD.EXE does delete files with invalid names. Using SFNs in this special case?)

One issue you might have is that even though a filename is LFN, there might not be an associated SFN, in which case the Win32SFNsearch would not help...

If there is no valid long filename and no valid short filename, then you're basically ... well, the forum probably rejects posts containing certain words. But at that point you're down to low-level disk access, which I don't imagine Rex would touch with a 30-foot double-insulated pole.

 

[thedave]

On Tue, 05 Apr 2011 14:11:58 -0400, Charles Dye <>
was claimed to have wrote:

>I'm cleaning up one of the file servers this week, and have to cope
>with numerous files with blatantly illegal filenames. (Damn Mac
>users.) And to my chagrin, I'm having to use CMD.EXE to fix them.
>
>Take, for instance, "12340_contents.pdf
>" (that's 82 spaces on the end -- I swear I'm not making this up!)
>Neither TCC nor CMD.EXE can cope with this, of course. Using CMD.EXE,
>I can delete the monster using its short filename, 12340_~2.PDF. In
>TCC, this doesn't work. It appears that TCC thoughtfully converts
>the SFN back to the corresponding (illegal) long filename, so I either
>get an error message or else whack the wrong file.

Have you tried the \\?\ syntax to bypass some of the API issues with
unusual file names?

If you're not familiar with it, just add \\?\ in front of the fully
qualified filename.

Something like "\\?\C:\Users\Dave\Documents\Stupid .pdf"
might work, for example.

 

[Charles Dye]

Have you tried the \\?\ syntax to bypass some of the API issues with unusual file names?

If you're not familiar with it, just add \\?\ in front of the fully
qualified filename.

That works in CMD.EXE. TCC sensibly strips off the trailing spaces, but I can make it work by replacing them with question marks.

 

[Kachupp]

try something like this NOT TESTED!

dir /b *.* >simple.txt

do r=0 to %@lines[simple.txt]
set file_%r=%@strip[" ",%@line[simple.txt,%r]]
: do renaming here it should still preserver the original name without
the extra's
enddo

> -----Original Message-----
> From: Charles Dye
> Sent: Wednesday, 6 April 2011 6:12 a.m.
> Subject: [Support-t-2754] File management via SFNs
>
>
> I'm cleaning up one of the file servers this week, and have
> to cope with numerous files with blatantly illegal filenames.
> (Damn Mac users.) And to my chagrin, I'm having to use
> CMD.EXE to fix them.
>
> Take, for instance, "12340_contents.pdf
> "
> (that's 82 spaces on the end -- I swear I'm not making this

 

[vefatica]

These aren't really illegal names, are they? I can make and delete one with CMD using the "\\?\" syntax.

v:\> echo foo > "\\?\e:\workplace\spaces.txt   "

v:\> for %f in ( s*.txt* ) do echo %f**

v:\> echo spaces.txt   **
spaces.txt   **

v:\> del "\\?\e:\workplace\spaces.txt   "

v:\> for %f in ( s*.txt* ) do echo %f**

v:\>

I can do neither with TCC.

 

[Charles Dye]

These aren't really illegal names, are they? I can make and delete one with CMD using the "\\?\" syntax.

Every MS document I can find on the subject (not many) says that this kind of thing is not kosher. For instance: http://support.microsoft.com/kb/117258

Whether or not to strip trailing spaces in the local-UNC \\?\ syntax: I think you could argue it either way. The current implementation is probably nicest 99% of the time -- i.e. always, except when dealing with this particular form of mangled filename.

 

[samintz]

Can't you quote the filename? It seems
odd that question marks work but nothing else.

-Scott

Charles Dye <> wrote on
04/05/2011 05:34:52 PM:

> That works in CMD.EXE. TCC sensibly strips off the trailing

spaces,

> but I can make it work by replacing them with question marks.
>
>
>
>

 

[Charles Dye]

Can't you quote the filename? It seems odd that question marks work but nothing else.

Double quotes get the spaces past the parser. But then they get stripped off later on. Somewhere in the filename handing code there is a subroutine which knows that trailing spaces are illegal, and corrects the defective filename for us.

Which is all well and good, as far as I'm concerned. The LFN is illegal -- I don't expect TCC to work with illegal filenames, I don't think it's appropriate to expect that. What I would like is to be able to use the other filename, the SFN, which is valid and usable.

TCC file-handling commands automatically substitute the LFN for a SFN. And in most cases, I think that also is a nice and reasonable feature, but in this particular case it happens to bite me. I can imagine a couple of ways to improve this:

1. A user-configurable option to disable automatic SFN-to-LFN translation. Probably the easiest to implement, though not very elegant.

2. Enhance the SFN-to-LFN conversion routine to recognize certain kinds of broken LFNs. If the equivalent long filename ends in a space or period, or if it contains a slash, backslash, colon, question mark, asterisk, or various other undesirable characters, then use the SFN rather than the LFN.