About Data Sharing Between Windows and UNIX

A communication protocol such as ftp, http or NFS is required for sharing data between Windows and UNIX.

The ftp and NFS protocols can be used for sharing data between these environments. Several implementations of NFS exist, provided by different vendors.

The following products have been tested using different scenarios:

HummingBird NFS Maestro Version 6.1
Intergraph DiskAccess Microsoft 2.0.

Limitations

Whatever technical solution you choose for sharing your data, make sure you are aware of the system limitations on file names described in About Filenames.

Data Sharing Scenarios

To illustrate the data sharing possibilities from UNIX to Windows , different kinds of scenario have been performed:

Transferring data by ftp.exe on a command window.
Transferring data using the Hummingbird ftp graphic Interface.
Transferring data by TAR, ftp and WinZip command successively.
Reading data using NFS Hummingbird.
Reading data using DiskAccess Microsoft.

Note: all these scenarios are based on exchanges from UNIX to Windows for filenames containing National or Special characters and Windows forbidden characters.

Transferring Data from UNIX to WINDOWS by ftp Protocol

Scenario 1: By ftp.exe on a Cmd.exe Window

ftp.exe transfer	Mput *.model	Put 'real filename'.model	Get 'real filename'.model	Mget *.model
AB+CD.model on UNIX**	KO	KO	KO	KO
AB CD.model on UNIX	KO	KO	KO	KO
AB+CD.model on Windows	OK	KO	KO	OK
AB CD.model on Windows	OK	OK	OK	OK

** (+ ) in the filename corresponds to the Plus/Minus character (0xb1)

Scenario Description

The first two V4 models were transferred from a UNIX login (Windows server is inetinfo). The last V4 models were transferred from a Windows login by ftp.exe client.

Conclusion:

Transferring V4 data must be done only from Windows . Data exportation from UNIX must be excluded if some special characters ( like 0xb1) have been frequently used on the V4 site.

Scenario 2: By Hummingbird ftp on Windows (Graphic Interface)

ftp.exe transfer	Mput *.model	Put AB+CD.model	Get AB+CD.model	Mget *.model
AB+CD.model on Windows	OK	OK	OK	OK
ftp.exe transfer	Mput *.model	Put AB CD.model	Get AB CD.model	Mget *.model
AB CD.model on Windows	OK	Not done	Not done	OK

Scenario Description

The V4 models have been transferred from Windows login using the ftp graphic command provided by Hummingbird. Conclusion: the graphic interface can be useful for a small numbers of transfers.

Note: Concerning national character transfer, the ftp configuration must be in mode "NO filename verification" (which is the default).

Scenario 3: Transferring by TAR UNIX IBM 932 / FTP / WINZIP Windows ISO1

Model name IBM932	Model name ISO1 Windows	V5 reads model
AB'Japanese'CD.model	OK (Garbaged characters)	OK
AB+CD.model	OK	OK

**The characters obtained after transferring Japanese filenames are garbaged because the resulting code page on Windows is ISO1.

Scenario Description

The V4 models were created on UNIX IBM932. The first one contains Japanese katakana SBCS characters and the second one the Plus/Minus character.

The TAR command is run on UNIX.

The FTP.exe command is run on Windows for transferring data.

The WinZip utility is run on Windows to extract the above mentioned data.

Scenario 4: Transferring by TAR UNIX IBM 932 / FTP / WINZIP Windows IBM932

Model name IBM932	Model name IBM932	V5 reads model
AB'Japanese'CD.model	OK	OK
AB+CD.model	OK	OK

Scenario Description

The V4 models have been created on UNIX IBM932 . The first one contains Japanese katakana SBCS characters and the second one the Plus/Minus character.

The TAR command is run on UNIX.

The FTP.exe command is run on Japanese Windows for transferring data.

The WinZip utility is run on Japanese Windows to extract the above mentioned data.

Conclusion: mixed environments can lead to unpredictable behavior on the filename. Our recommendation is to use the same code page (ISO 646 subset). Consequently, V4 models have to be read in the same code page where WinZip utility has been performed.

Reading UNIX data from Windows

Scenario 5: Using HUMMINGBIRD NFS

Model name under UNIX	Model name read in V5 Windows
AB+CD.model	KO : Strange unicode character
AB>CD.model	KO : Invalid name in File/Open box
AB<CD.model	KO : Invalid name in File/Open box
AB*CD.model	KO : Does nothing
AB?CD.model	KO : Does nothing
AB"CD.model	KO : Invalid name in File/Open box
AB:CD.model	KO : 'AB' result

Scenario Description

A few V4 models containing Windows forbidden characters are read directly using NFS MAESTRO HUMMINGBIRD.

Conclusion

If the model name contains:

national characters ( and especially +- 0xb1)
metacharacters * and ?
special characters

the CATIA V5 File/Open box rejects them.

Using NFS Hummingbird 6.1 can be recommended only if the NT_COMPATIBILITY value has been employed in the V4 CATIA declaration file to prevent future data corruption.

Scenario 6: Using DISK ACCESS Microsoft

Model name under UNIX	Model name read in CATIA V4 Windows
AB+CD.model	OK
AB>CD.model	KO : Invalid name in File/Open box
AB<CD.model	KO : Invalid name in File/Open box
AB*CD.model	KO : Does nothing
AB?CD.model	KO : Does nothing
AB"CD.model	KO : Invalid name in File/Open box
AB:CD.model	KO : AB resulting

Scenario Description

A few V4 models containing Windows forbidden characters are read directly by DiskAccess.

Conclusion:

Although DiskAccess refused also the forbidden Windows characters, it is possible to read National ones ( for instance, Plus/Minus character ).

The same scenario has been performed between a Japanese UNIX and a Japanese Windows machine: equivalent results were obtained .The Plus/Minus character and Japanese directories containing V4 models can be read directly by DiskAccess.

General Recommendations

We recommend that, when using these products, you activate the lock mechanism and keep the same case in file names.

We also recommend that you evaluate the product within the context and environment of your company before deploying it, in order to check that it meets your needs and is appropriate for your processes.