| > Question on the MSA volume also a PC volume. Customer has created a
> WORD document and named it Myfile.01 on the PC share. She needs the
> file only on the PC, so it was not a problem. One day the folder that
> contains the MyFile.01 was moved from this Mac volume to another Mac
> volume by a Mac user, this PC WORD file is not readable anymore. Why?
In this case the file was mostly likely copied (_NOT_ MOVED) and as a
result each record (as defined by RMS) was read by the Mac, and written
to a new file. The DECshare file server would have used the Rules
established in MSAF$FILE_TYPES.DAT to determine if the file needed to
be converted or left alone. My guess is that according to the rules,
the file server thought the file was a TEXT file. Since the PATHWORKS
for OpenVMS (LANMAN) file server stores DOS files as RMS Stream
<CR><LF> file, the DECshare file server will strip all bytes with the
value of hex 0x0A <LF> which follow a hex 0x0D <CR>. The resulting
file would no longer be a valid MS-WORD file.
Fix the MSAF$FILE_TYPES.DAT file and reboot the DECshare file server,
then use a Mac tool such as FileTyper, or ResEdit, or Norton Utilities
Disk Editor to fix the Type/Creator pair so that the Mac no longer
thinks the file is a TEXT file. Another way to get the Type/Creator
pair changed is to use the PC or OpenVMS to rename the file (after
fixing the MSAF$FILE_TYPES.DAT file and rebooting the file server).
> If the folder that contains this file "MYFILE.01" was moved within the
> same volume to another folder by a Mac user, the PC file is still redable.
That the equivalent of using the OpenVMS RENAME command to move a file
between to directories (in fact the operations performed by the
DECshare file server are very similar to those used by the OpenVMS
RENAME command).
As a result the file is never opened, never read, and no attempt is
made to decide if a conversion is required.
> 1. What is the difference between this two copy actions?
See above.
> 2. Is there a way to recover from the problem that the file is no longer
> readable?
Very unlikely. However, if you can figure out where the 0x10
characters were deleted in the file and can put them back, then you
might get lucky, but since you don't know if a 0x0D by had a 0x0A
character following it, you don't know if you should add a 0x0A or to
leave it alone.
> I always thought the Mac folder drag and drop is the safest way to
> preserver all files attributes (Mac and PC). That is not the case for
> this particular case. The problem with this file is the extension is
> wrong to map to the Mac side. Why the same volume copy preserve it
> nicely and different volume completely changed the file? It is
> puzzling.
Files created by Macs always have the correct Type/Creator pair, plus
the RMS file created by the DECshare file server does not need any
conversions by the file server. However files created by OpenVMS or PC
clients have an unknown Type/Creator pair and the DECshare file server
doesn't know it it should be treated as a TEXT file or a binary file,
so it looks at MSAF$FILE_TYPES.DAT the very first time it sees the file
and decides on the Type/Creator and the conversion rules to be applied
to the file. Once it decides it records that information away for that
file and never looks at the MSAF$FILE_TYPES.DAT again for that file
unless the file is renamed on the PC or OpenVMS (which effectivily
makes the file look like a new file again).
If you are just moving PC or OpenVMS files within the same volume, then
contents of files will not be touched (exactly the same as using RENAME
on OpenVMS). But if you cross volumes all bets are off for PC or
OpenVMS files unless you have your MSAF$FILE_TYPES.DAT file setup
correctly. Again Mac files are already stored with all the right
informaion.
> We are working with CSC on this problem. I have been trying to do some
> more tests as well. It is true for WIN3.1 users, WORD 6.0C, Macintosh
> version is 7.51, MSA is 1.3-ECO2. PW50D-ECO3. Same problem for NT 4.0
> users on PC side, running WORD for NT.
Again, correct your MSAF$FILE_TYPES.DAT file. Then fix the
Type/Creator information on files that already exist (no changes to
MSAF$FILE_TYPES.DAT will change the recorded Type/Creator pair of
existing files, only the tricks I mentioned above will do that).
Bob Harris
|