A Windows file named report[final].txt can exist in File Explorer while a PowerShell command using its name behaves unexpectedly. Square brackets have wildcard meaning for parameters such as Get-Item -Path. To inspect exactly that filename, use Get-Item -LiteralPath. Quoting a path protects spaces and controls shell interpretation, but quotes alone do not turn a wildcard-aware parameter into a literal one.
This is a read-only troubleshooting workflow for the filesystem. It does not require an administrator terminal, a filename change or a change to PowerShell execution policy. Start with a harmless text file rather than a downloaded executable or a sensitive production document.
Distinguish quoting from wildcard matching
Two different interpretation steps cause confusion. PowerShell first interprets the command text, including quotes and variable expressions. The receiving command can then treat a parameter value as a wildcard pattern. A single-quoted string can therefore still contain brackets that -Path interprets as a pattern.
Consider the literal filename report[final].txt. Brackets in a wildcard pattern denote a character set, so that pattern is not a reliable request for the bracket-containing filename. Depending on the other files present, a wildcard-aware lookup might find no match or a different file. Neither result proves that the exact file is missing.
Microsoft documents Get-Item with separate Path and LiteralPath parameter sets. Its parameter reference explicitly says that LiteralPath uses the value as typed and does not interpret characters as wildcards. This is the appropriate distinction for the bracket problem.
Inspect the exact file without opening its contents
Suppose the file really is located at the example path below. Replace that path with your own confirmed full filename. In a PowerShell terminal, use these separate statements:
$file = 'C:\Users\Public\Documents\report[final].txt'
Get-Item -LiteralPath $file -ErrorAction Stop | Select-Object FullName, Length, LastWriteTime, PSIsContainerThe example selects metadata rather than launching the document. Review FullName to confirm the intended object, PSIsContainer to distinguish a directory from a file, and the remaining fields for basic context. Size and modification time do not establish that contents are trustworthy or correct.
The example location is illustrative; it does not create a file there. If the lookup fails, copy the actual path from File Explorer and check spelling, extension and location. Keep the variable value single-quoted when entering a fixed path containing characters such as a dollar sign. If you intentionally build a path from variables, review the resulting value before using it.
Handle errors without weakening protections
A missing-item message can mean the path is wrong, the file moved or your view of the folder is incomplete. An access-denied message is a different problem. Do not grant broad permissions or switch to an administrator shell merely because a filename contains brackets: literal matching fixes interpretation, not access rights.
Hidden items require a separate visibility decision. Microsoft notes that Get-Item -Force can retrieve otherwise hidden items in supported providers, but it does not override security restrictions. Use it only when investigating a known visibility issue. It is not a general solution to every lookup failure.
Also confirm which command you are actually calling if your terminal behaves differently from an example. Profiles can define functions or aliases, and shells use different command rules. The related tutorial on where.exe, the where alias and Get-Command explains why command identification matters before changing system settings.
Carry the exact-path habit into later steps
After identifying a file, do not assume that every later command treats its name literally. Check the next cmdlet’s parameter help. Where supported, explicitly use -LiteralPath again rather than returning to a positional wildcard-aware path argument.
This matters especially before copy, rename or deletion operations. The metadata inspection here does not authorise those changes. If your actual task requires editing or moving a file, preserve the original and test the exact operation on a disposable copy first. Do not treat a successful read-only inspection as a rehearsal proving that a destructive command is safe.
Short FAQ and final checklist
Should I rename every file containing brackets? Not just to inspect it. A literal-path lookup handles the name without changing a shared document, automation reference or audit record.
Will LiteralPath expand an asterisk? No. It is for the exact value, not a search pattern. For intentional searches, choose a wildcard-aware parameter deliberately and inspect the complete result list.
Does it make a file safe to run? No. Matching a name says nothing about malware, publisher identity or file integrity.
- Confirm the complete filename and extension.
- Use an explicit literal-path parameter for a single exact item.
- Inspect the returned full path before any follow-on action.
- Investigate permission failures separately from matching failures.
This tutorial is for educational use. Test carefully before applying steps in production. The site owner is not responsible for misuse, damage, data loss or production issues.
