1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

File management via SFNs

Discussion in 'Support' started by Charles Dye, Apr 5, 2011.

  1. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    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.)
     
  2. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    TCC is great for finding these monstrosities, using a wildspec like "*[ ]". So for now, I'm using a two-shell approach....
     
  3. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  4. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    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?)

    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.
     
  5. thedave

    Joined:
    Nov 13, 2008
    Messages:
    254
    Likes Received:
    2
    On Tue, 05 Apr 2011 14:11:58 -0400, Charles Dye <>
    was claimed to have wrote:


    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.
     
  6. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    That works in CMD.EXE. TCC sensibly strips off the trailing spaces, but I can make it work by replacing them with question marks.
     
  7. Kachupp

    Joined:
    Aug 9, 2009
    Messages:
    133
    Likes Received:
    0
    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


     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    8,129
    Likes Received:
    33
    These aren't really illegal names, are they? I can make and delete one with CMD using the "\\?\" syntax.

    Code:
    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.
     
  9. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    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.
     
  10. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,203
    Likes Received:
    11
    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:


    spaces,

     
  11. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,374
    Likes Received:
    40
    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.
     

Share This Page