File name of 255 characters and path up to 32,727 symbols are supported by Automation Workshop

There are certain limits of file name and path lengths in the Microsoft Windows. These limits are very high for most practical purposes, thus not encountered very often, and because of that, are somewhat vaguely understood. In this discussion I am mainly going to refer to NTFS file system as the currently most advanced file system supported by Windows (some parts or this article may also be true for FAT32 or exFAT); and Unicode as UTF-16 or in some places may be UCS-2 (only 65,535 chars). One well known limit is that filename cannot be longer than 255 Unicode symbols. Another popular limit is 260 Unicode characters – maximum whole path length under Windows.

By putting these two constants together you can model various examples of path limits, for example, you can create the following paths:

  • C:\1\2\3\4\5\6\7\8\9\0\a\… [about 16,383 similar folders] …\your-file.txt
  • C:\[Folder name consisting of 255 chars]\[Another long folder]\some-file.txt
  • C:\Text\From\Average\Wikipedia\Article\As\File\Path\Easily\Fits\Here\…
  • \\Server\Share\Very\Long\Path\Is\Supported\For\UNC Paths\…

So how many is these 65,535 symbols/characters? As you can see in the above examples, the whole Wikipedia article (average English) fits into path name, even when every word is separated with backslash character (\). And actually you need to separate words in the path with backslash, because of each file / folder name has a limit of 255 characters.

If you try to create such file, folder or path in the Windows Explorer, you won’t succeeded. Windows Explorer won’t let you do that, and it may not show any error, it simply may limit how many symbols you can enter. But this part depends on the Windows version. For example, Windows 8.1 Pro sometimes show an error:

The file name(s) would be too long for the destination folder. You can shorten the file name and try again, or try a location that has a shorter path.
The file name(s) would be too long for the destination folder. You can shorten…
Different error, if using Windows 7 Ultimate - Destination Path Too Long
Different error, if using Windows 7 Ultimate – Destination Path Too Long

Even latest Microsoft OSes – Windows 8.1 and Windows Server 2012 R2 cannot display / manage these folders correctly. It won’t allow you to click on the last folder that is visible, and it does not show path longer than ~512 chars. It simply does not show up, but it is there. Also, it does not refresh the folder content, so it shows the last “state”. In our case it is the same folder that we are inside. See the screenshot below:

Windows Explorer can not handle long path
Windows Explorer can not handle long path

Also, Windows Explorer does not allow you to delete such folder. It shows the following error on Windows 8.1 Pro:

Source path too long - The source file name(s) are larger than is supported by the file system. Try moving to a location which has a shorter path name, or try renaming to shorter name(s) before attempting this operation.
Source path too long

Also, it says “The source file name(s) are larger than is supported by the file system…”, which is a bit misleading. It is not supported by Windows Shell, not the file system. But perhaps that message is meant for novice users, not administrators and PC experts.

Windows Shell is not the only sub-system that can’t handle such paths. For example, CMD.exe, also can not:

cmd.exe - The filename or extension is too long
cmd.exe – The filename or extension is too long

Even newest PowerShell gives up:

PowerShell The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters
PowerShell The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters

There are plenty of situations where 260 characters is not enough. For example, HTTP request has limits from 2,083 to 8,192 characters, and you want to use file system directory structure for your web application. Or perhaps your a backup application is configured to backup all user files to location “C:\Username\2014-Aug-27\Some-other-folder\” and what happens when user have already created path with a maximum of 260 characters? A Backup program should never fail, and so we must be able to overcome this limit.

What about Automation Workshop?

All file / folder actions and triggers, and many other actions and services of Automation Workshop support very long file and path names. Even more, the free edition also supports this all right out of the box. There are some limitations here and there. For example, it may be cumbersome to enter very long path in the standard input fields. However, there are very handy means to overcome this. The Variable Wizard’s “Read from file” is one of them:

Read from file - Variable Wizard
Read from file – Variable Wizard


  • Filename length of 255 characters is not hard-coded. Windows API GetVolumeInformation can return greater values in future, however I have never seen lpMaximumComponentLength to be more than 255.
  • Another program that supports very long paths is newer versions of Far Manager (open source application). I believe, that most file managers are not limited as Windows Explorer, but I have not tried them.
  • Microsoft article about File naming, Paths, including 8.3 filenames, reserved characters, Namespaces. Read here.
  • Another article from Microsoft – Windows Fundamentals. Particularly section 1.3 Support Long File Names and UNC paths.

From scripting to Visual tool and back to scripting

In the beginning there was a IT World without an easy to use automation solution. Then came Febooti Software and in November 03, 2008 they released Automation Workshop. And IT professionals were happy, because they could create Automation Workshop’s Tasks using GUI, instead of writing boring Batch (.bat) scripts, VBScripts, JScripts or even PowerShell scripts.

This is our story. After the launch of Automation Workshop, we were happy, because many recurring tasks now could be created without writing single line of code. Our users were happy too, because they could reduce costs by using our software.

But time passed and support requests came in. And many people were perfectly satisfied with Automation Workshop, however they needed some small thing/tweak/feature/improvement that were not available using Automation Workshop’s standard features.

So now in year 2011 we released Automation Workshop v1.1 that features a new Action – Execute script.

This is Action that can execute JScript (.js), VBScript (.vbs), PowerShell (.ps1) and Batch (.bat) scripts. Now we are feeling that we are somehow returned to the starting point where users need to write scripts, write code instead of using elegant and intuitive GUI tool. But this is not the same place where we were in 2008. Now users can combine both strengths – Visual GUI tool and power of the scripting.

Also, it is interesting to note that this new action Execute script combines scripting from 3 different PC eras:

  • Batch file – 1981 (with the first version of MS-DOS);
  • JScript – 1996;
  • VBScript – 1996;
  • Windows PowerShell – late 2006.