Skip to main content

Accessing and Writting files to Access Connect Volumes

Thread needs solution
Beginner
Posts: 1
Comments: 0

I am writing a PowerShell script to modify specific files that have been written to our Windows File Servers. The file servers are running EZ-IP Version 9. I have come across many folders and files that have strange characters contained in them. For example here is a directory name that I have, ImageViewer™ You will notice the TM at the end of the folder name.

Now when I get a listing to a file from PowerShell using the Get-ChildItem cmdlet that folder actually looks like this in the file, ImageViewer? The TM now is a ?.

Now from within my PowerShell script I can list out the files under that folder, verify the files exist using the Test-Path and I can also delete the files using the Remove-Item cmdlet. But when I use the Add-Content cmdlet I get errors stating the object is not found.

How can I access this folder from PowerShell? Should I specify a different -encoding parameter on the Get-ChildItem? Can I convert just that entry when I hit the error to represent what is actually there and allow me to write the file?

Any and all help on this would be greatly appreciated.

Thanks..

0 Users found this helpful
Senior Support Engineer
Posts: 0
Comments: 56

ExtremeZ-IP can detect and reject the Mac client attempting to save (create, rename, move) files with characters that are "illegal" in Microsoft Explorer or other applications that don't support the Unicode file system APIs. Examples: \ / : * ? " < >. However, the reported characters (e.g.: ™) are not illegal they are just high Unicode. So, it is not an ExtremeZ-IP related issue but a Unicode vs. PowerShell one.

I have an idea: you can create a file (not a folder) named: test™.txt. Then you can add this to the filename policy under "Specific characters" and run a Filename Policy Violations report to find all instances of files with this name (folders won't work): http://www.acronis.com/en-us/support/documentation/AccessConnect/#30114…. Report shows '[2122]' is not allowed, so the Unicode value is '[2122]'.

If you google PowerShell and Unicode characters - it seem that it may be complicated to get Unicode to work properly, so it may be better to use another tool. Here are some hints about Unicode and PowerShell: http://serverfault.com/questions/313695/powershell-2-how-to-strip-a-spe….