Long file names used in user redirected folders trigger issues

Topic

New Reply

Michael McElrath reported this yesterday and Born city follows up that after the Excel patch is installed that files with a long path length – meaning
[See the full post at: Long file names used in user redirected folders trigger issues]

Susan Bradley Patch Lady

1 user thanked author for this post.

Casey S

Reply | Quote

Replies

Back to MS-DOS restrictions with LFN’s?

Keeping IT Lean, Clean and Mean!

Reply | Quote

Something in the filter is not quite right with redirected folders.

Susan Bradley Patch Lady

Reply | Quote

May also impact mapped drives.

Susan Bradley Patch Lady

Reply | Quote

I can confirm it affects mapped drives.  Win Server 2019, Win 10 Pro, Excel 2013.  Gives two different errors, one it’s corrupt and won’t open.  The other is the extension doens’t match, but offers the opportunity to open this “corrupted” or “unsafe” file.

Depending on the length of the filename, it seems the problem appends all or part of the file extension to the filename field:

• CamSpecs.xlsx  shows as CamSpecsxlsx in the error messages.
• PoLow.xlsx shows as PoLowx in the error messages.

I’m certain someone at MS is counting down the days to April 11, 2023… 🙂

1 user thanked author for this post.

Microfix

Reply | Quote

Casey S wrote:

I’m certain someone at MS is counting down the days to April 11, 2023… 🙂

…the same could be said for Jan 10th 2023

Keeping IT Lean, Clean and Mean!

Reply | Quote

This is a brand new (18 July 2022) MS article that seems on point:

https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

In the past, I had big problems with long path/file names in OneDrive. A client routinely used file names that were quite long.  The files were stored locally on NAS and backed up to OneDrive. OneDrive failed to accept so many files that it was unusable. Turned out that OneDrive had some pretty good-sized paths that were prepended to “visible” path and file name.

I don’t know if this has been fixed or not because I’ve tried to use it again.

Reply | Quote

I’ve seen similar problems with files in (roaming) User Profiles not synchronising correctly to the server because of files / paths being too long. The Max_Path length in the MS article explains how applications can create files / paths beyond 260 characters. Most applications can indeed create very long files / path names. But then there’s Windows Explorer who chokes on those files. Since applications have no problem reading / writing those files, I wonder if, in the case of Roaming Profiles, Windows uses functions of Explorer to copy files and then fails at very long file names / paths.

Quote from the article: The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.

Reply | Quote

Simon_Weel wrote:

I’ve seen similar problems with files in (roaming) User Profiles not synchronising correctly to the server because of files / paths being too long. The Max_Path length in the MS article explains how applications can create files / paths beyond 260 characters. Most applications can indeed create very long files / path names. But then there’s Windows Explorer who chokes on those files. Since applications have no problem reading / writing those files, I wonder if, in the case of Roaming Profiles, Windows uses functions of Explorer to copy files and then fails at very long file names / paths.

Quote from the article: The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface is not able to interpret properly.

Wouldn’t it be nice if Redmond would put a few fewer people on screwing up the Windows interface and a few more people on fixing things that have been a problem for years?

3 users thanked author for this post.

JPMedia, NaNoNyMouse, Ricard

Reply | Quote