Regarding the problem with long file names, Jeff Chandler (from Microsoft) states: "I have seen this happen. Usually it is because the file has a character in the name that the other OS won't allow or can't recognize. Basically it happens because the two platforms use the same character sets for ASCII (roughly characters 0-127) but the upper (also called extended) characters are different. For example, if you name a Mac file and put a '\' in the name, you can't write it to a DOS disk because that's the character DOS uses to specify directories. Or it'll let you copy the file, but then the DOS system won't recognize it." Microsoft has a new Knowledge Base article on this matter.
Another reader claims: "Although the new version of PC Exchange 2.2 does support Windows 95 long filenames, the rest of the OS does not yet support the long filenames. We have to wait for OS 8.2 to have full compatibility with Win 95 long filenames. Right now, PC Exchange converts the Win95 long filenames into shorter filenames."
Regarding more general copying problems, Phill Bogart points to the Mac invisible files that normally get written to a PC floppy disk when opened on a Mac: Finder.dat, Desktop and OpenFolderListDF. If you try to make a copy before the Finder writes these files (or if there is not enough room on the floppy to hold these files), the problems described last time will occur. Glenn Myers confirms this and offers a work-around: "Copy one file over, then drag it to the trash which must empty. The remainder of the files will then be copied normally." Paul Christensen similarly notes that these invisible files may sometimes not get updated when you delete files on a floppy disk, leading to problems; deleting the invisible files and thereby forcing new copies to be made, may fix the problem.
Brett L. Kessler offers a related explanation: It's because of the Mac's data fork/resource fork split. When a PC-formatted disk is inserted into a Mac, some invisible files are written. In addition to the 'standard' Finder.DAT file (etc.), each directory gets an invisible directory named Resource.FRK, and this folder contains an invisible file for every file in the parent directory; this file contains the resource fork's information for the file. For example, if I use my Mac to place a file called "Picture.GIF" into the top level of a PC-formatted floppy disk, the Mac also creates an invisible folder called "Resource.FRK", containing an invisible file called Picture.GIF. This invisible file contains the Mac's resource fork of Picture.GIF. Now I take this disk to a PC, and delete the file Picture.GIF from the top-level directory. The PC, which knows nothing about the invisible Resource.FRK folder, only deletes the Picture.GIF from the main folder, not the associated resource folder. If I take that disk back to my Mac, and try to copy a file called Picture.GIF to the root directory, the Mac also tries to create the invisible Picture.GIF in the "Resource.FRK" directory - but the file already exists there, so it can't."
Chris Little adds: "On examining the disk on the PC, I found that the file for the resource fork was still on the disk using the original filename. Deleting this file allowed me to copy the file from my Mac to the PC disk. It would seem that 8.1 won't copy a file to a PC disk if a resource fork file with the same name already exists."
A couple of readers correctly noted that the first part of Bob Rodenburg's problem, of moving the file to the desktop not copying the file, is normal behavior for the Mac. Holding down the Option key when dragging the file should get the copy to work as desired. The problem that remains unexplained is that the file disappeared entirely.
Allan Herman claims that the version of PC Exchange that comes with Mac OS 8.1 (version 2.2) caused the copying problem noted last time by Robert Jung. The version of PC Exchange that came with Mac OS 8.0 worked.