BUG: Shared Folders fail if filename contains brackets

dkp said:
If you use a Posix environment in Windows (U/Win, MKS Toolkit) you'd like to manage file names without any intervening layer making decisions for you. And you'd like your regular expression special characters to work as expected. While I'd avoid like the plague using such characters in file names in the first place, I'd like those characters to remain well-behaved when they are used in a regex context.

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 :P) 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.
 
Last edited:
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!
 
murfle said:
(Assuming I wrote my regex right, I just woke up :P) 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.

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.
 
dkp said:
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...
 
Back
Top