Searching for long file names

Topic

New Reply

While I was copying files from one folder to another, I got a warning that there were filenames included that were longer than 256 characters. Rather than dealing with each one at that time, I just continued the copying.

Is there a process or program that I can use to scan a folder and find all the files with “too long” names, and move them so that I can then deal with them — rename perhaps — later?

Regards,
Chuck Billow

Chuck Billow

Reply | Quote

Replies

Chuck,

You really have file names that are that long? Are you sure it isn’t the File spec, e.g. drivepathfilename.ext?
The only work around I know is to flatten your tree out (fewer levels) or to copy at a lower level. HTH :cheers:

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

RG, no, it’s the whole path, and in fact I never actually saw a problem, so I guess I just shouldn’t worry about it.

Chuck

Chuck Billow

Reply | Quote

Windows doesn’t have a length issue, but Windows Explorer does. The easiest way to fix the issue is to rename (shorten) the folder names that contain the offending files until you can work with the files themselves. Alternatively use Robocopy to move the files to a shorter path.

cheers, Paul

Reply | Quote

Paul,

Both MS & I disagree.

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is “D:some 256-character path string” where “” represents the invisible terminating null character for the current system codepage. (The characters are used here for visual clarity and cannot be part of a valid path string.)

Here’s thefull article on MS Tech Net.

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

Paul,

Both MS & I disagree.

Here’s thefull article on MS Tech Net.

The linked article contains a treasure trove of information about file and path naming conventions. Some interesting tidbits:

Reserved characters:
(greater than)
: (colon)
” (double quote)
/ (forward slash)
(backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

Reserved names:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9

To request 8.3 file names, long file names, or the full path of a file from the system, consider the following options:
•To get the 8.3 form of a long file name, use the GetShortPathName function.
•To get the long file name version of a short name, use the GetLongPathName function.
•To get the full path to a file, use the GetFullPathName function.

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the “\?” prefix. For example, “\?D:very long path”.

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior. A registry key allows you to enable or disable the new long path behavior. To enable long path behavior set the registry key at HKLMSYSTEMCurrentControlSetControlFileSystem LongPathsEnabled (Type: REG_DWORD).

Group "L" (Linux Mint)
with Windows 10 running in a remote session on my file server

Reply | Quote

… you must opt-in to the new behavior.

Hmmm, that’s interesting. Opt-in functions imply that Microsoft believes there might be some problems or downsides to the new long path capability. Perhaps with people still using FAT volumes (speculation)?

Or it might imply that Microsoft hasn’t analyzed the consequences enough and wants more time.

Or it might imply that someone messed up and forgot to activate Long Paths (D’oh!).

Reply | Quote

Hmmm, that’s interesting. Opt-in functions imply that Microsoft believes there might be some problems or downsides to the new long path capability. Perhaps with people still using FAT volumes (speculation)?

Or it might imply that Microsoft hasn’t analyzed the consequences enough and wants more time.

Or it might imply that someone messed up and forgot to activate Long Paths (D’oh!).

I think they’re just trying to stay backward compatible. Forcing you to opt in will make sure that you realize that you’re going down a path which won’t work with the way things have always been done.

Group "L" (Linux Mint)
with Windows 10 running in a remote session on my file server

Reply | Quote

RG, I’ve used / fixed many a long path in Windows, but it may be because I was working with servers / 64bit software.

cheers, Paul

Reply | Quote

Paul,

Yes, the hardware/software can be very different on servers. :cheers:

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

Copy/paste the following into a Notepad file and save it as FilepathChecker.vbs:

Code:

Dim oShell
Set oShell = CreateObject(“Wscript.Shell”)

Const FOR_READING = 1
strFolder = InputBox(“Enter the filepath (local or UNC) you wish to query, e.g. C:Windows or \servershare$folder”)
‘strFolder = “C:Windows”

Set objFSO = CreateObject(“Scripting.FileSystemObject”)

‘Create a file to pipe the results to
LogFileName = oShell.SpecialFolders(“Desktop”) & “FilePathLength.txt”
Set fsHandle = objFSO.OpenTextFile (LogFileName,8,True)

‘Recurse through folders and get the full path of files, inc. in sub-folders
Set objFolder = objFSO.GetFolder(strFolder)
fsHandle.Writeline objFolder.Path
Set colFiles = objFolder.Files
For Each objFile In colFiles
  fsHandle.Writeline “(” & Len(objFile.Path) & ” Chrs) ” & objFile.Path
Next
ShowSubFolders(objFolder)
 
Sub ShowSubFolders(objFolder)
  Set colFolders = objFolder.SubFolders
  For Each objSubFolder In colFolders
    fsHandle.Writeline objSubFolder.Path
    Set colFiles = objSubFolder.Files
    For Each objFile In colFiles
      fsHandle.Writeline “(” & Len(objFile.Path) & ” Chrs) ” & objFile.Path
    Next
    ShowSubFolders(objSubFolder)
  Next
End Sub

oShell.Popup “Check the FilePathLength.txt file on your desktop.”, 3, “Path length checker”

Wscript.Quit()

When you run it you’ll be asked to enter a starting point (like C: or C:Windows, etc.) When it’s finished there’ll be a text file on your desktop called FilePathLength.txt. In the file you will see a list of your files prefixed by the numbers of characters. Tested on Windows XP and Windows 7.

Hope this helps…

Reply | Quote

Many thanks for this code, it works perfectly!

Reply | Quote

Thank you Rick! Worked like a charm! :rolleyes:

Copy/paste the following into a Notepad file and save it as FilepathChecker.vbs:

Code:

Dim oShell
Set oShell = CreateObject(“Wscript.Shell”)

Const FOR_READING = 1
strFolder = InputBox(“Enter the filepath (local or UNC) you wish to query, e.g. C:Windows or \servershare$folder”)
‘strFolder = “C:Windows”

Set objFSO = CreateObject(“Scripting.FileSystemObject”)

‘Create a file to pipe the results to
LogFileName = oShell.SpecialFolders(“Desktop”) & “FilePathLength.txt”
Set fsHandle = objFSO.OpenTextFile (LogFileName,8,True)

‘Recurse through folders and get the full path of files, inc. in sub-folders
Set objFolder = objFSO.GetFolder(strFolder)
fsHandle.Writeline objFolder.Path
Set colFiles = objFolder.Files
For Each objFile In colFiles
  fsHandle.Writeline “(” & Len(objFile.Path) & ” Chrs) ” & objFile.Path
Next
ShowSubFolders(objFolder)
 
Sub ShowSubFolders(objFolder)
  Set colFolders = objFolder.SubFolders
  For Each objSubFolder In colFolders
    fsHandle.Writeline objSubFolder.Path
    Set colFiles = objSubFolder.Files
    For Each objFile In colFiles
      fsHandle.Writeline “(” & Len(objFile.Path) & ” Chrs) ” & objFile.Path
    Next
    ShowSubFolders(objSubFolder)
  Next
End Sub

oShell.Popup “Check the FilePathLength.txt file on your desktop.”, 3, “Path length checker”

Wscript.Quit()

When you run it you’ll be asked to enter a starting point (like C: or C:Windows, etc.) When it’s finished there’ll be a text file on your desktop called FilePathLength.txt. In the file you will see a list of your files prefixed by the numbers of characters. Tested on Windows XP and Windows 7.

Hope this helps…

:rolleyes:

Reply | Quote

Hey Y’all,

For those who might be interested here’s a PowerShell version with options to control mininum size reported and write to a CSV file:

Get-LongFileNames.ps1 46881-Get-LongFileNames

Here’s the messages it puts out:

Invalid Path:
46882-LFN-InvalidPathMsg

No Files Found:
46883-LFNNoFIles

Output File Location:
46884-LFN-FileWrittenMsg

What the csv file looks like in excel when column B set to Wrap Text and lengthened:
46885-lfnexcel

HTH :cheers:

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

The thing is though, there have to be logic holes in the file name length restrictions.

Many times over the years, I’ve created filenames that were too long and later I had to shorten. If the rules were fundamental, creating that filename would have been prohibited in the first place. And that includes all the path information. Therefore the issue really isn’t different whether the problem is with a FQFN or just the FN.

Yes, it happens more often when you copy from an NTFS volume to a DVD for instance. However that’s because CDFS has more restrictive naming rules than NTFS.

On this forum no more than a week ago I mentioned how I had a too-long name on NTFS and I couldn’t edit the name to correct the problem. That does not involve CDFS, at all. So how come I was able to create the name with the problem in the first place?

:confused:

Reply | Quote

On another note, it’s fantastic to see the programmers and problem-solvers among us, coming up with solutions.

:clapping:

Reply | Quote

Windows doesn’t have a name length restriction any more but Explorer, and possible other things, does, so a program may create long file names and then when you attempt to use them in Explorer it appears to be broken.

cheers, Paul

Reply | Quote

I remember reading somewhere that a total of 256 characters can be squeezed into a folder & file name “one-liner”; for lack of better technical English; I hope somebody can explain far better than I. I’m in a middle school cafeteria with noisy kids and distractions.

"Take care of thy backups and thy restores shall take care of thee." Ben Franklin, revisted

Reply | Quote

Thanks to all!

Chuck

Chuck Billow

Reply | Quote

I think they’re just trying to stay backward compatible.

I know this is nearly a 2-year-old post but my comment would be to look at the presence of new hardware/computers that still need Microsoft’s Media Creation Tool to create Bootable USB drives that are formatted as FAT32 for installing Windows 10, therefore retaining backward compatibility. I believe the only way to get away from backward compatibility would be to wipe out all current technology and write new to change things, not going to be an easy task by any means. An example of problems would be the internal combustion engines in cars and trucks we’ve been using for over 100 years, no easy way to get away from petroleum products.

Before you wonder "Am I doing things right," ask "Am I doing the right things?"

Reply | Quote