BUG: Shared Folders fail if filename contains brackets

Exactly! You're using a posix environment. That's the one that will be doing the work of translation, not the share's host. If you use a regex to select 10 files (for example), the posix system will tell the share which 10 files those are... it won't pass the regex through. Therefore, your point is not valid, since you'd have to escape those characters in the posix environment if you want them to remain literal. This acts no differently than if you were doing everything on a local filesystem.

Lets say you have these files on your share.

a[1].txt
a[2].txt
a[3].txt

Run the following to copy them to your local filesystem (as long as your shell handles regex)

$ cp /share/a\[[1-3]\].txt .

(Assuming I wrote my regex right, I just woke up ) Your posix system will find that there are the 3 files, and ask for 3 files... The share does not necessarily handle regular expression (at least not in all cases, and I'm pretty sure not in this one). See? I just wrote an example of something that handles both of our scenarios.

 

Well, just tested things out on v3.0, and its still a problem. Due to lack of response from Parallels (and I've seen many posts by them in other threads on this forum), you have lost another potential customer, and you can be sure I'll be spreading the word on all the mac communities of your horrible customer service and shady business practices.

Buyer beware!

 

And that is what I expect, too. The problem comes in if Parallels does something because somebody wanted to have Samba-like filename support, and fiddles with the characters. And you did good with the escaping for having one eye open and also demonstrated why I maintain it's insane to use special characters in Unix file names. Avoid them if you can, fight with them if you cannot. This is clearly a bigger issue for scripts than interactively dealing with them.

Some of the Unix directories I work with have millions of files in a single directory (yes, that is insane, too) and having to deal with the overhead of escaping special characters is tedious. Certainly not impossible, but one layer of insane at a time is good for me.

So if they can fix your problem without creating one for me we'd both be happy.

 

Yes, it is possible to fix the problem without creating one for you.

For me, escaping is second nature, and it comes pretty easily for me, so I generally don't need to avoid, or fight with them... thats why I'm not too concerned about having them in my filenames.

so:

a.txt
b.txt
c.txt

if they fix the bug, you can still:

$ cp /share/[abc].txt .
and I can still
$ cp /share/\a\[1\].txt .

But as I stated, I doubt parallels will ever fix this bug, since I will never pay for their software...

 

Hi,

The bug was found and fixed. Please wait awile for the next 3.x update.

Alex