Skip to content

Directory.GetFiles fails when the directory has a file with 255 characters in the name #57578

Description

@Const-me

Description

Critical error in Directory.GetFiles function

Configuration

Using .NET Core 2.1 LTS.

The OS is Debian Linux, OS kernel 4.4.132+.

The architecture is ARMv7, 32-bit. The CPU is Rockchip RK3288.

I don’t know whether it is specific to that configuration, but based on the source code in your repository, the bug probably affects all Linux regardless on the rest of the factors.

According to Linux documentation, files names of 255 characters are valid on all supported file systems except FAT32.

Linux command-line shell is also fine with such files. The scp integrated into sshd server also handles them fine. It’s very unexpected for .NET Core to not be able to handle such files, especially since the file was previously created by other pieces of the same C# standard library.

Other information

I've attached the repro project. Here’s the output:

File name length: 255 characters
Created OK
Read OK: Hello, world
Fail: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
   at System.ReadOnlySpan`1..ctor(Void* pointer, Int32 length)
   at Interop.Sys.DirectoryEntry.GetName(Span`1 buffer)
   at System.IO.Enumeration.FileSystemEntry.get_FileName()
   at System.IO.Enumeration.FileSystemEnumerableFactory.<>c__DisplayClass3_0.<UserFiles>b__1(FileSystemEntry& entry)
   at System.IO.Enumeration.FileSystemEnumerable`1.DelegateEnumerator.ShouldIncludeEntry(FileSystemEntry& entry)
   at System.IO.Enumeration.FileSystemEnumerator`1.MoveNext()
   at System.Collections.Generic.LargeArrayBuilder`1.AddRange(IEnumerable`1 items)
   at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at System.IO.Directory.GetFiles(String path)
   at Program.mainImpl()
   at Program.Main(String[] args)

P.S. Unfortunately, that was not a synthetic test. Our customer has actually uploaded the file with such a long name. This bug has broken an expensive device with embedded Linux. I incorrectly assumed that if a file was successfully created, written and read using .NET’s FileStream-based classes, the name should be good enough for the rest of the file system APIs.

Metadata

Metadata

Assignees

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions