BUG: Shared Folders fail if filename contains brackets

[drtimhill]

There appears to be a bug in the Shared Folders feature of PW for Mac if a filename contains square bracket characters. Specifically, if a filename on the Mac has square brackets in the name, the file will *appear* in the shared folder on Windows but will not be accessible by Windows Explorer or any application. Attempts to access the file trigger error message such as "file not found" or similar.

Steps to repro:
1. Setup shared folders normally under Mac and Windows XP, so Windows can "see" a Mac folder.

2. On the Mac, place a Word document (say, "foo.doc") in the shared folder.

3. In Windows, double-click the folder and note that it opens in Word. Close the document and exit Word.

4. On the Mac, rename the file to "foo [stuff].doc".

5. Back in Windows. Double-click the renamed file. Note that it does NOT open and an error occurs (the error message depends on the app, but in effect it says that the app cannot access the file).

The file can be renamed on the Mac to remove the brackets and all will be well again. Note that this behavior is NOT restricted to Word and .doc files: other applications and file types exhibit the same behavior.

Note: I have determined that square brackets cause this behavior, while parentheses do not. I have not tested extensively with other special characters. I have also NOT tested on the current beta (RC) of PW, only the current production release.

Tim

 

[drtimhill]

Update: As of build 1970, this bug is not fixed -- it is still not possible to open files in shared folders that have square brackets in the file name.

For me, this is a show-stopper, since I have literally hundreds of such files.

 

[hhwong]

Update: As of build 1970, this bug is not fixed -- it is still not possible to open files in shared folders that have square brackets in the file name.

For me, this is a show-stopper, since I have literally hundreds of such files.

This works for me. I can open files with square brackets in my share folder.

 

[miker51]

For me, this is a show-stopper, since I have literally hundreds of such files.

I'm not so sure that this is a Parallels bug. I know that Windows, and in particular Office apps are very picky about how a filename is structured.

 

[Marko]

Having [...] in a file name can be quite common under Windows...

Ever have an anti virus program installed that renamed files you download (as it has to scan the download file first) and the file is renamed with [1], [2] etc for each version downloaded...

so it is not a Mac vs PC thing...

BTW... I test this by launching an executable installer with "[1]" in the filename located in my shared folder... it worked.

Must be your Office Apps...

 

[drtimhill]

No, it's not my apps --- it does it in Explorer as well. Interesting that it's working for some people and not others. I shall have to experiment further.

--Tim

 

[Mark Reddick]

I just tried this and here is what I'm experiencing:

I put a file named "test.rtf" into a shared folder. In the VM, WordPad was able to open it fine and I can copy it from the shared folder to the Windows desktop. All well and good.

I then renamed the file on the Mac side to "test[1].rtf". In my VM, WordPad opened it fine. However, if I try to copy that file off the shared folder, Windows Explorer errors with "Cannot copy file: Cannot read from the source file or disk". I can also open the RTF file in WordPad and save it to my desktop without a problem.

I then renamed the file on the Mac side to "test/test.rtf. This is an invalid name in Windows. It appears Parallels is a bit smart about this and in the shared folder in the VM it shows up as "test:test.rtf". I try to open the file with WordPad and I get the error "\\.PSF\Shared Files\test:test.rtf The specified path does not exist. Check the path, and then try again." I then tried opening it in Word and Word opens it but it generates the error "There is insufficent memory. Save the document now. (\\.PSF\Shared Files\test:test.rtf)". If I try to copy the song from the shared folder to the desktop, nothing appears to happen. Then, if I try copying it a second time, I get an error "Cannot copy xtest: The file exists.".

So, it seems it really doesn't like the whole : or / in file names which is a bit understandable since these are folder separators on Mac and / on Windows) and they are illegal to use in their respective system's file names.

BTW, I'm running Parallels Build 1970 and this was done in a Windows XP SP2 fully updated VM.

Update:
I just noticed that I now have a file on my desktop (in my VM) named "test" and one named "~$st". These must have been put there when I tried copying the file with the : in the name. And, I cannot delete these files from the desktop. If I try to delete them, Windows errors with the message "Cannot delete file: Cannot read from the source file or disk. So, as of now, it appears I am stuck with these garbage files on my desktop.

Update 2:
I was able to delete the "test" file from the command prompt. However, it doesn't let me delete the "~$st" file. I just noticed this file is flagged hidden. I tried unhiding it using the ATTRIB command but it reports that it cannot change the attribute.

Update 3:
Ok, I was finally able to delete that hidden file. I ended up using a utility named "Delete FXP Files". It turns out the file name had a space at the end. Windows doesn't like that.

 

[murfle]

This is still a bug in 3188... Is there any intention of fixing this? I'm doing the 15 day trial now, since I just got my mac two days ago, but if this isn't fixed, it going to nullify one of the two main reasons I was going to purchase this software...

And renaming my files is NOT an option.

 

[dkp]

This is still a bug in 3188... Is there any intention of fixing this? I'm doing the 15 day trial now, since I just got my mac two days ago, but if this isn't fixed, it going to nullify one of the two main reasons I was going to purchase this software...

And renaming my files is NOT an option.

Brackets in Unix file names is insane. Those brackets mean things. Following is an OS X shell command session where junk1.txt, junk2.txt, junk12.txt, and junk[12].txt are created using the touch command, and then listed using ls:

# create test files with "touch"
$ touch junk1.txt
$ touch junk2.txt
$ touch junk12.txt

# list them with "ls"
$ ls junk*
junk1.txt junk12.txt junk2.txt

# list files using brackets in the name
$ ls junk[12].txt
junk1.txt junk2.txt
# The brackets in this context mean use 1 or 2 in this position, so it lists both files even though neither file has brackets in their names

# now try to create a file with brackets in the name
$ touch junk[12].txt

# and list them again
$ ls -l junk*
junk1.txt junk12.txt junk2.txt
# No file with brackets was created. This is expected. What touch did was change the modification time of the files with either 1 or 2 but not the file with 12 in the name.

# Now create a file with brackets in the name but protect the brackets from the shell with quotes
$ touch "junk[12].txt"

# and list them with a wild card
$ls junk*
junk1.txt junk12.txt junk2.txt junk[12].txt
# The new file with brackets is there

# now list them as before
$ ls junk[12].txt
junk1.txt junk2.txt
# two files are missing from the listing

#Now use quotes
$ls "junk[12].txt"
junk[12].txt

# and finally, use a wild card again
$ls junk*.txt
junk1.txt junk12.txt junk2.txt junk[12].txt

Why would you want to do this? It's a hellish mess to manage.

 

[murfle]

I'm a perl programmer, so I'm well versed in regular expressions... That's what backslashes and quotes are for...

Also, OS X uses the bash shell (from what I've seen). In other UNIX variants, not all shells will use wildcards the same way, as far as i can remember... I've been using bash for the past 7 or 8 years, and can't recall much from ksh or tcsh which I used to use...

When you ask "Why would you want to do this", are you asking me, or the UNIX community in general? Either way, it doesn't matter. The fact is Parallels should be able to resolve this bug. You have a host O/S that allows special characters like this in their file names if you escape them properly (which the Mac OS GUI obviously does, since the files work just fine), and a Guest O/S that doesn't need to do anything with them...

You run into the same issue on UNIX systems with spaces in the filename... You have to use quotes or escape them... How does parallels deal with this? Maybe it just magically works, but I doubt it... I'm sure its not as easy as just adding the brackets to the same chunk of code, but I haven't seen their code... It might be as simple as s/\[/\\\]/g (or its equivalent search and replace in C or whatever language they wrote the software in)

 

[dkp]

Maybe you can explain how Parallels (software) would be able to understand your intent in using brackets in file names. Are you using them as literals or as regex special characters? What clues are you prepared to provide Parallels to help it make this determination or do you wish Parallels always to treat them as literals? If the latter, do you wish this for all special characters including slash characters? Can you imagine why others might prefer they do not? Why do you call this a bug?

 

[murfle]

Sorry, but your post makes no sense. The filenames are from a windows system, which I have already mentioned, and windows treat [ and ] as literal characters. If the guest windows O/S asks the host O/S for a file with a literal character that the host O/S considers regex, the virtual machine should handle it. If I can see a file on a share in a GUI, why shouldn't the software understand I want to copy the file when I drag and drop it to the guest O/S' local filesystem? Simple! Drag from a share, drop on a local filesystem. It copies. That 's what a GUI is for. To assume you intend it to do what it was created to do. Maybe you can show me where in the Windows GUI you can use regular expressions (out of the box)...

I set up samba on my host mac OS. Set up a share. Booted up parallels, and mounted the SMB share exactly the same way I mounted the the Parallels share, with a different drive letter. The SMB share has absolutely NO problem allowing me to copy the file. Copying it from the Parallels share gives the error described throughout this thread. Since samba is a *nix version of windows shares, it knows how to handle these things. I'm assuming parallels wrote their own sharing algorithms, and don't take these characters into account, where as tried, tested and working software does. However they implemented it, they didn't make it very robust.

I've also installed the beta version of VMWare Fusion. Mounting the VMWare version of a share also works as expected.

That is why I call this a bug.

Now you asked if I could imagine why others might prefer if they don't change this... No. I can't. Those files are effectively useless on the windows system if they reside on the host. You can't do anything with them. Maybe you mean some people may want to use a regular expression to copy files from the host into windows, from windows. Maybe you could explain how to do this (without something like cygwin installed), preferably with a base install of windows and parallels (with the tools) and nothing else. That isn't to say just because everything else works a certain way, parallels would need to, but at least state what its supposed to be doing.

Needless to say, dkp, I'm curious as to if you are affiliated with parallels, as it seems like you might be a developer who's just too lazy to fix something... That whole "Its not a bug, its a feature" saying won't work on me.

 

[dkp]

I don't work for Parallels and I'm sure that pleases them no end. I do live near them, though. However - you are asking Parallels (the software) to fiddle with special characters in file names but you need to remember that Parallels also supports Linux and Unix. That is why it is important to treat special characters with care. Samba is intended and written for Windows/Unix file sharing and so has, at the application layer, tools to deal with this. Parallels is the middle man between Unix/Unix, Unix/Windows, Linux/Windows, BSD... etc. It can't make too many assumptions. If this is handled by Parallels Tools in a host/guest OS context vs in the Parallels core then it should be possible to handle this in a user convenient way.

That still leaves OS X to sort out how to deal with such filenames just as Windows must somehow deal with mixed case file names in Unix. Junk.txt and junk.txt are two unique files in Unix as you know, but the same file in Windows. I'll end it by saying, certain characters are very problematic when used in file and directory names - it's certainly worth trying hard to avoid using them by design that to hack a work-around later.

 

[murfle]

When you're designing an architecture you have full control over, you have every right to say "Don't use these characters in your filenames". Parallels is writing software for a consumer level user base. You have to write the software for variances of systems.

Parallels Desktop for Mac is the software this bug is present on (I haven't checked on other versions) so the only host O/S you have to worry about is OS X. Therefore, this 'middleman' is all about OSX/Windows, OSX/Linux, etc... What you are saying is complete nonsense! If you're copying a file from the command line in linux from any windows-style share (samba, win2k server, whatever!), you would type
$ cp /sharemount/file\[whatever\].txt /destination/
or... if you were using a GUI file manager, and you drag and drop, it will put those slashes in for you! If it doesn't, file a bug report.

The point you are failing to see is that the software does NOT need to figure out what the user is asking... If the user is asking for multiple files from a windows share, it does not use regular expressions. Yes, certain characters are problematic. But a windows share is a windows share. It uses windows conventions. It considers brackets as literals, and it ignores case. If you copy Junk.txt from unix to windows, it keeps the case... if you copy junk.txt, it will overwrite the Junk.txt you just copied and keep the lower case version.

If you mount a windows share on ANY platform, it is still a windows share. It acts as a windows share. Parallels implementation does not act like a windows share with regards to these special characters.

VMWare Fusion handles all these different guest O/S', and has no problem.

Like I mentioned, I got things to work the way I want them with a samba share, so I could easily just buy parallels and use the little workaround.

My issue is I will not pay for software with a development team that does not even acknowledge a bug like this. Sounds like pure laziness and "Let's make cool stuff instead of creating a solid product" mentality.

Are you listening Parallels? Show me you care about my business.

 

[darkone]

this is probably caused by the internal SMB protocol that Parallels uses. Its had issues in the past with streams too. I'm only aware of this as the company i work for developed a product using an smb protocol built by our dev guys, which also had problems with streams and unicode characters.
I'd be suprised if an ALT+255 space character didnt bang up a similar error to the one you experience with []'s

on another note tho.. can you imagine how many bugs these guys have to fix.. I'm sure this is a queue, but to be honest, YOUR bug, may not be as important as MY bug etc... Annoying bugs like this one can hang around in the queue for a long time, depending on how many higher severity bugs are there to be processed. Laziness, I'm sure, doesnt come into it. You say youre a developer yourself, so I'm sure you know all about the development process and the support process.

 

[murfle]

Yes, I'm well aware of development process. I've also done my share of customer service, and that is my main problem here. I know this is a low priority, but parallels seems to have a communication problem. If its logged as a bug, just say so. I could respect that. Heck, if they came back and said "Our code is a tangled mess of spaghetti code, and I can't see it being fixed in the next five years", I could respect that. (Also, it would be nice to see a changelog with each release.)

I have to admit, I kept getting the impression dkp was trying to talk on parallels behalf, hence the lazy comment... So I must apologize for that remark.

 

[dkp]

When you're designing an architecture you have full control over, you have every right to say "Don't use these characters in your filenames". Parallels is writing software for a consumer level user base. You have to write the software for variances of systems.

Parallels Desktop for Mac is the software this bug is present on (I haven't checked on other versions) so the only host O/S you have to worry about is OS X. Therefore, this 'middleman' is all about OSX/Windows, OSX/Linux, etc... What you are saying is complete nonsense! If you're copying a file from the command line in linux from any windows-style share (samba, win2k server, whatever!), you would type
$ cp /sharemount/file\[whatever\].txt /destination/
or... if you were using a GUI file manager, and you drag and drop, it will put those slashes in for you! If it doesn't, file a bug report.

I never said it couldn't be done, or that escape characters are not appropriate - I said such characters in a Unix file system are insane. I haven't changed my mind or yours I just don't want Parallels to make decisions about my choices that I can't work around.

 

[murfle]

I never said it couldn't be done, or that escape characters are not appropriate - I said such characters in a Unix file system are insane. I haven't changed my mind or yours I just don't want Parallels to make decisions about my choices that I can't work around.

I really want to know what these choices of yours are... I've been trying to think of a scenario where this bug is actually beneficial, but haven't been able to think of anything...

 

[rawhead]

I'm chiming in, this really kills the new "Parallels Explorer" feature for me, as the files I'd like access to on my Parallels/Windows drive image often contain brackets. Well, back to using good ol' SAMBA on OSX (which handles those files no problem, albeit being slow).

 

[dkp]

I really want to know what these choices of yours are... I've been trying to think of a scenario where this bug is actually beneficial, but haven't been able to think of anything...

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.