-
-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get-ChildItem2 fails if UNC-Path contains .lnk file #46
Comments
I'm seeing the same error on a directory that has no .lnk files in it, but it does have an odd zero-length .xlsx file whose name starts with a When I change that |
I am able to reproduce the error with a directory containing a .lnk file. |
I can confirm the problem with leading $ in the filename, but only if the file is on a share. |
For what it's worth, I'm unable to reproduce this error with or without the dollarsign on the .lnk file.
I also tested the example that @karlheinz-hildebrandt mentioned in his first post but wasn't able to get the same error. I did change it from '\' to '.\' which I think is required as the latter pulls from the root drive rather than the current folder. I should also mention that both work though.
If I move into a UNC path and then run the command on the current location I get an error though it's not the same one.
I'm unsure if any of this helps but I hope so. |
I'm having a similar issue, but I can offer some additional specifics on when it occurs. In my case it doesn't seem to have anything to do with .lnk files. As others have indicated looks like the leading character of the filename matters. So far I've found the problem with the following leading characters -, +, #, {, $ . Without hunting for every possible character I think it's fair to say the issue occurs with any legal, leading non-alphanumeric character. Note: It's very tough to control file naming in the wild, so all of these are problematic. However, the "$" leads many names in the common $RECYCLE.BIN folder. I presume this would only increase the prevalence of the issue. Similar to what James pointed out, my reproductions have been a little inconsistent though. When testing locally it seems harder to reproduce, for example in c:\temp. This remains true even when I use the UNC to the local path. I also had some difficulty reproducing it in a purely remote folder when starting the interrogation at that same level, but that's been inconsistent so far. Also note I discovered the problem in Remove-Item2, but can reproduce and have tested with Get-ChildItem2. I haven't looked at any code so I don't know if one leverages the other. Sorry if this is coming to the conversation late. I hope it's helpful. |
Thanks for reporting this issue. Working on it... |
This is a bug in AlphaFS which I cannot solve quickly. The issue is tracked in alphaleonis/AlphaFS#460. |
Thanks for all your hard work. I've actually been using the module for years. Don't rush on my account. The permission stuff is working fine I use it all the time. I only encountered the error in a script where I was expecting paths >260 chars. I went back to the core *item cmdlets but using the \\UNC\... syntax. |
Hello Raimund,
The full command I'm using to obtain the path items:
The items in that path WebEx\wbxcache are definitely 7Zip files, but when do basic get-childitem on same path shows as Directories. Same error in a different location:
Hope it helps. |
I'm receiving a similar error:
This is a repeatable error. When I perform a Get-Item on same path:
It has a single file in that path that has a "," comma as the first character in the filename. Hope this helps. |
Using Get-ChildItem2 on a network UNC-Path shows error, if the folder contains a .lnk file. Error is:
Get-ChildItem2 : (3) The target directory is a file, not a directory: [\]
In Zeile:1 Zeichen:1
Using Get-ChildItem runs without problem.
The text was updated successfully, but these errors were encountered: