PowerShell extended property `BaseName` for `DirectoryInfo` is inconsistent when there is an `extension`

[Hashbrown777]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

This occurs on both windows and linux, starting at v5 all the way through to now.
<#System.IO.FileInfo#> | %{ $_.BaseName + $_.Extension } should always be equivalent to <#System.IO.FileInfo#>.Name
For gci -File this holds true.
For gci -Directory although pwsh correctly has .BaseName always match .Name (folders cannot have extensions..), .Extension incorrectly matches .Name -replace '^.*?(?=\.[^.]*$|$)','' instead of always returning ""

Expected behavior

PS> (New-Item -Type Directory -Name 'bob.steve 123_456[yoyo]').Extension

PS>

Actual behavior

PS> (New-Item -Type Directory -Name 'bob.steve 123_456[yoyo]').Extension
.steve 123_456[yoyo]
PS>

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.4.2
PSEdition                      Core
GitCommitId                    7.4.2
OS                             Fedora Remix for WSL
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

[Hashbrown777]

$_.Name.Substring($_.BaseName.length) is a succinct way to reliably get the accurate Extension

[rhubarb-geek-nz]

Where is the rule defined that a directory cannot have a file extension?

A directory is still a file, and on POSIX systems the file system does not know about extensions at all, a file extension is purely down to an application's interpretation.
The Windows file system is aware of file extensions to a point, since 8.3 names but with NTFS and ability to have multiple periods in a name it is not really the role of the file system to make any inferences.

On a Linux system you will find many directories ending with ".d" under /etc and I would consider that a file extension.

So extension is really in the eye of the beholder.

PS> get-childitem .

    Directory: /home/bythesea

UnixMode         User Group         LastWriteTime         Size Name
--------         ---- -----         -------------         ---- ----
drwxr-xr-x     bythesea users      04/30/2024 06:17         4096 foo.bar

PS> get-childItem . | Select-Object -Property Extension,BaseName

Extension BaseName
--------- --------
.bar      foo.bar

[Hashbrown777]

On a Linux system you will find many directories ending with ".d" under /etc and I would consider that a file extension.

Yes, and in those cases the basename would exclude the ".d"; you cannot have it both ways.
Also, having ".steve 123_456[yoyo]" as an extension is a far cry from ".d", but instead of asking for a reform of how powershell interprets extensions, I just want it to be consistent; if it says directories basenames are always the same as the name, then the extensions must always be empty.

[rhubarb-geek-nz]

Yes, name != basename + extension

PS /etc> get-childitem rc* | Select-Object Name,BaseName,Extension

Name     BaseName Extension
----     -------- ---------
rc0.d    rc0.d    .d
rc1.d    rc1.d    .d
rc2.d    rc2.d    .d
rc3.d    rc3.d    .d
rc4.d    rc4.d    .d
rc5.d    rc5.d    .d
rc6.d    rc6.d    .d
rcS.d    rcS.d    .d
rc.local rc       .local

[Hashbrown777]

Yes, name != basename + extension

And where is that defined? (genuinely, it's not there)
I'm pretty sure in every language basename is defined in terms of full path sans the parent directories and any extension.
https://linux.die.net/man/1/basename
https://www.php.net/manual/en/function.basename.php

Posting more examples of what I'm describing as a bug isn't helping prove anything?

Most languages either A dont provide a basename, allowing the application to be the beholder as it were, or B allow said application to provide the suffix explicitly. Powershell has taken it upon itself to interpret the extension, and if the programmer decides to use this value, the API needs to be self-consistent.

Just a moment...

PHP: basename - Manual

[rhubarb-geek-nz]

Yes, name != basename + extension

And where is that defined?

Sorry, I was just confirming what I was seeing, that the basename still had the ,d on the end

[Hashbrown777]

I was just confirming what I was seeing

Ah, I thought that was an offered explanation; "Yes, [because] name isnt.." not "Yes, [I see in pwsh] name isnt.."

But seriously, it's bizarre I can't find doco on .Basename..

[rhubarb-geek-nz]

This occurs on both windows and linux, starting at v5 all the way through to now.

This may make it hard to make any change other than document the behaviour. We don't have any idea how much existing code is relying on the existing behaviour.

[Hashbrown777]

existing code is relying on the existing behaviour.

Dont let pwsh be another cmd.exe, we'll see what the devs say. No-one would be relying on this, they'd be compensating for it.
That's kind of why we have a v7 in the first place, people who write code stuck in time stay on 5

[237dmitry]

$ gi ./foo.bar/ | ft Name, BaseName, Extension

Name    BaseName Extension
----    -------- ---------
foo.bar foo.bar  

$  gi ./foo.bar | ft Name, BaseName, Extension 

Name    BaseName Extension
----    -------- ---------
foo.bar foo.bar  .bar

[Hashbrown777]

That's an interesting observation, and unfortunately not leverageable as a workaround (like for the example screenshot) :(

[rhubarb-geek-nz]

$ gi ./foo.bar/ | ft Name, BaseName, Extension

That's an interesting observation, and unfortunately not leverageable as a workaround

The Microsoft build tools keep the trailing slash on directory names, so you don't need to append it when constructing full paths, eg

   <FilesToDelete Include="$(PublishDir)$(AssemblyName).deps.json" />
   <FilesToDelete Include="$(PublishDir)$(AssemblyName).pdb" />

It has a couple advantages

• you can look at the string, not the file system to see if it is a directory or not
• if it is not set, the worst you can do is in the local directory rather than the root of the file system

However you do need to look for both '/' and '\'

[Hashbrown777]

I'm unsure how that's relevant to an example that just wants to treat directories and files the same and have the output be predictable, nothing's trying to append paths or fetching items directly using known paths.

For instance, trying to "clone" a directory by making symlinks whilst injecting into the new names:

gci 'version1/' | %{ ln -s $_ "export/$($_.BaseName).version1$($_.Extension)" }

Knowing gi $directPathWithSlash changes $_.Extension wont help because "$_" is a result of a search, not picking up a specific path. Using $_.Name.Substring($_.BaseName.length) in place of $_.Extension does function though.

[jborean93]

But seriously, it's bizarre I can't find doco on .Basename..

BaseName is not a property on the DirectoryInfo/FileInfo types in .NET but part of an ETS member added by PowerShell. You can see that on PowerShell 7 it's a ScriptProperty that is simply an alias for Name for DirectoryInfo and a more complex script property for FileInfo

PS /home/jborean> Get-Item $pwd | Get-Member -name BaseName

   TypeName: System.IO.DirectoryInfo

Name     MemberType     Definition
----     ----------     ----------
BaseName ScriptProperty System.Object BaseName {get=$this.Name;}

PS /home/jborean> Get-Item $PSHome/pwsh | Get-Member -Name BaseName

   TypeName: System.IO.FileInfo

Name     MemberType     Definition
----     ----------     ----------
BaseName ScriptProperty System.Object BaseName {get=if ($this.Extension.Length -gt 0){$this.Name.Remove($this.Name.Length - $this.Exte…

You can also use Get-TypeData to see that the BaseName property is set on the type and not just manually added to the instance by Get-Item

PS /home/jborean> (Get-TypeData System.IO.FileInfo).Members.BaseName

GetScriptBlock                                                                                                   SetScriptBlock IsHidde
                                                                                                                                      n
--------------                                                                                                   -------------- -------
if ($this.Extension.Length -gt 0){$this.Name.Remove($this.Name.Length - $this.Extension.Length)}else{$this.Name}                  False

PS /home/jborean> (Get-TypeData System.IO.DirectoryInfo).Members.BaseName

GetScriptBlock SetScriptBlock IsHidden Name
-------------- -------------- -------- ----
$this.Name                       False BaseName