The filename you've specified is either invalid or too long - even though filename is not too long!

[jfsm]

Hi folks, I'm having a issue in TrueNas that is preventing me from copying some files to my PC desktop from my TrueNas system. I'm using SMB on Windows 10 to access my TrueNas system. The error I'm getting is "The filename you've specified is either invalid or too long.". I've checked the length of the path, and it's only 131 characters in the case of the example below. I get this same error with other files in the same directory, and there are other directories on my system that share the same issue.

If I duplicate the file below within the same directory, via copy and paste, so that I have a new duplicte file called "A0176 - Copy.MXF", I'm able to drag the duplicate to my desktop, but not the original file.

This issue causes Premiere Pro's Project Manager to fail when I attempt to collect a project's files.

Example file:
(Note that I've changed some of the letters to *'s to anonymise the project, but there are no *'s in the path)
\\192.168.1.50\shared\Archive\A******\A****** - V* (Multiple Projects)\A**18089 - V* Y***B****** Phase 2\Footage\Supplied\A0176.MXF
The unix path is /mnt/tank/shared/Archive……… so no longer than the Window file path above.

I'm using Windows 10 20H2 19042.1288, and TrueNAS-12.0-U6 installed on a 45Drives Storinator.

 

[Macaroni323]

jfsm,

I've seen the same on Windows 10 myself. Originally I thought that this was a Windows Update problem (I am on 21H1). I have a FreeNAS server that was just upgraded to 11.3-U5 and I have been seeing this issue (though I didn't connect the upgrade to the issue myself). I backup the server to a hard drive on a Windows 10 machine and do binary compares (Scooter Software Beyond Compare) every so often to look for errors (I've had "data rot" appear on the the Windows machine hard drive 1 or 2 times in 4-5 years based on files that do not binary compare suddenly, like a zip file that was not readable on the backup but WAS readable on the FreeNAS system, or a JPG that appears damaged on the backup but not on FreeNAS). The binary compare flagged the "data rot". I also see binary compare bit errors sneak into the network or the remote computer that will not reappear after re-testing the binary comparison a second time (the backup drive is located on a non-server machine and reading the server via the network and doing binary data compares).

Recently I have many files that will not compare do to strange errors. The files look OK on both sides... To my best guess they don't appear damaged. At a closer look I try to copy the file to my Windows machine and it won't copy do to the filename being invalid or too long. These files were compared many times previous to this with no issues. When copying to MacOS there's no issue.

I did read somewhere that having AFP and SMB services enabled at the same time could be the issue. There may be something in that since if I connect the backup drive to a Mac that I have and do the compare there is no issue. Since I've turned off AFP and I'm using SMB via all machines and I have a new issue that I haven't gotten to the bottom of... A ZIP file that fails compare has changed size on a Windows 8.1 machine relative to the server and the backup drive for the server. The filesize is showing different and the filedate has changed. This may be a coincidence but unzipping the both files results in binary identical data in both zips. I copied the Windows 8.1 ZIP file to a Windows 10 workstation and then tried to copy the ZIP from the server and... The invalid filename issue appears. Copying both files to my Macbook Pro works fine, while the ZIP files will not binary compare but expanding both ZIPs and comparing the data expanded works perfectly. Copying to a Windows 8.1 machine also fails with the same error.

Another test... On the Windows machine, I browse to the server and find the "file in question". I copy the ZIP on the server and the paste directly in the same directory on the server getting <filename> - copy.zip and that works. I binary compare both files (both Beyond Compare and 010 Editor) and they're identical. I can highlight both files and copy them to the Windows machine and the copy works fine and the original fails for invalid filename. I then rename the "file in question" and rename the copy matching the original "file in question's" name. The renamed "file in question" will still not copy to Windows without the failure and the renamed copy is fine.

Not sure what's going on. Maybe there is a permissions issue that needs to be checked here. I have a feeling that I have 100's if not 1000's of files that are this way, especially since I freely move between Mac and Windows machines.

Still testing...

 

[Heracles]

Hey @jfsm

This is why I got rid of Windows over 15 years ago now... It is nothing but crap and it is simply to worst operating system on the market, period.

So for your case, Yes, your name is indeed too long. Here, you have 2 stupid things at once from Windows.

First is that the error message is misleading. What is too long is not the --FILENAME-- but the complete path that includes the filename. To shorten some directories names in the path should help you.

Second is that such a limitation is ridiculous and should not even exist, but alas... it does and Yes, Windows is unable to handle full path that goes beyond a certain limit (256 if I remember properly...).

So my recommendation is to start by reducing the length of some of your parent directory to drop back to something that Windows will handle. Once done, re-design your tree structure to avoid nesting too many subfolders because that is something Windows can not handle.

Of course, the best would be to get rid of Windows completely if you can...

 

[winnielinnie]

If I duplicate the file below within the same directory, via copy and paste, so that I have a new duplicte file called "A0176 - Copy.MXF", I'm able to drag the duplicate to my desktop, but not the original file.

That is highly strange. Permissions issue that Windows 10 incorrectly deems "file path too long"?

 

[Macaroni323]

I've checked the length of the path, and it's only 131 characters

This is unrelated to the path length in my case. My path is about 52 characters and I get the same issue. I do understand Windows will lead you astray on errors sometimes.

Ran the "stat" command from the FreeNAS shell and then "icacls" command from Windows command prompt and I can see no differences that would explain the issue. Though copying the bad file to the same directory and deleting the original, and then renaming the copy to the original filename seems to workaround my issue.

 

[jfsm]

Hey @jfsm

This is why I got rid of Windows over 15 years ago now... It is nothing but crap and it is simply to worst operating system on the market, period.

So for your case, Yes, your name is indeed too long. Here, you have 2 stupid things at once from Windows.

First is that the error message is misleading. What is too long is not the --FILENAME-- but the complete path that includes the filename. To shorten some directories names in the path should help you.

Second is that such a limitation is ridiculous and should not even exist, but alas... it does and Yes, Windows is unable to handle full path that goes beyond a certain limit (256 if I remember properly...).

So my recommendation is to start by reducing the length of some of your parent directory to drop back to something that Windows will handle. Once done, re-design your tree structure to avoid nesting too many subfolders because that is something Windows can not handle.

Of course, the best would be to get rid of Windows completely if you can...

Hi Heracles, my full path character length in that example above was 131 characters, so well under the 256 character limit. And when I duplicate the problematic files within the same TrueNAS directory, I'm able to copy the duplicates from the that same directory to my desktop, just not the originals.