10.3.6アップデートで共有フォルダトラブル

共有フォルダでアクセスできなくなったのをリストアップしてみましたところ、フォルダ名が長いものが全てダメになっていました。
確認用に新しく共有フォルダを作成しフォルダ名をいろいろ変更してみたところ、全角４文字までＯＫ（全角５文字以上はダメ）でした。
半角文字では９文字まででした。
ちなみにマックからSMBで共有フォルダにアクセスするとやはり全角５文字以上のフォルダは表示されませんでした。
念のためバックアップに取っていた10.3.5OSXseverで起動し、全角１０文字の共有フォルダを作成しWindowsからアクセスできることを確認し、そのまま10.3.6にアップデートしましたら、やはりwindowsからは見えない（マックでもSMB接続では見えない）ようになってしまいました。
10.3.6でWindowsとの更なる連携機能強化が行われたようですが、これは？？？

全てのWindowsマシンから全角５文字以上の共有フォルダにアクセスできないのではありませんでした、スミマセン。
全角５文字以上の共有フォルダにアクセスできないケース
・Windows98、Me、マックからのSMBによる接続
全角５文字以上でも問題なくアクセスできるケース
・WindowsXP、NT
Windows2000はネットワーク内にないので確認できていません。
今までどのクライアントからも問題なく共有ファイルにアクセスできていたのに、これからはＸＰ系以外はサポート対象外となってきているのでしょうか？
けど、マックからのSMBによるアクセスでも今まで問題なくアクセスできていた共有フォルダにアクセスできなくなっているなど、私としては困る仕様変更です。
みなさんのOSXserver 10.3.6では問題ないですか？

共有フォルダは確認してませんが、長いファイル名のデータはAFP経由で文字化けします。他でも同様の症状が出る方がいらっしゃいましたので、同じ内容のトラブルに近いかもしれませんね。
OS9ならいざしらず、OSXでロングファイルネームのトラブルは今更勘弁して欲しいです。
とりあえずFTPとSMBでしのいでます。

Kaz.さん、レスありがとうございます。
AFPでも文字化けするのですか？それはまだ未確認でした。
さっそく確認・注意しておきます。
ファイル名管理関係でやはりトラブルが起こっているのですね、ちょっと安心しました（利用環境が原因のトラブルかもしれないと思ってましたので）。
アップルさん、早く対応アップデータを出してもらえないかな？？

私の環境でもファイル名の文字化けが発生しています。
ただ確認した限りでは、MacOSX 10.3.6 + PathFinderを使っている友人が自分のサーバにアクセスした際ははノントラブルなんですよね。
もしかするとクライアント(MacOSX 10.3.6)側のFinderのバグなのかな?

サーバ：MacOSX Server 10.3.6
クライアント：Mac OSX 10.3.6(PathFinder無し）
クライアント：windows XP Home(SP2)
Macからafpでアクセスし、クライアントにコピー：
　サーバ上のファイル名とクライアントのファイル名が共に、２１バイト又は２２バイト以降で文字化けする。
　但し、アンマウントしてから再度、マウントすると、サーバ上のファイル名は回復している。
Macからsmbでアクセスし、クライアントにコピー：
　サーバ上、クライアント上、何れも文字化け無し。
Winからアクセスし、クライアントにコピー：
　サーバ上、クライアント上、何れも文字化け無し。
という結果でした。
フォルダ名も同様であることを確認しました。
afpとsamba両方に対応する２種類のNASを使っていますが、何れも同様のバグがあり、MacOSX serverへ戻すこと検討していましたが、これでは困ってしまいます。

完全にAFPのバグだと思います。
フィードバックも行いましたが、反応はありません。
英数字でも発生しているので日本だけの問題じゃないはずです。
かなり困ったトラブルなんですが、大きな問題として取り上げられないのはなぜなんでしょう・・・？

米国でも話題になっているようです。
http://discussions.info.apple.com/webx?14@@.689eb619

サーバ、クライアント共に10.3.7にして、４０文字（全角）プラス拡張子のファイルをAFPで相互にコピーしました。どちらのコピーでも、コピー元、コピー先のどちらも、ファイル名が維持されています。
sambaは未確認です。

ロングネームの共有フォルダはだめでした。
ま、アップデート情報にもAFPでのロングネーム対応修正は書いてありましたが、SMBについては書いてなかったのでダメかなとは思ってましたが。
Windowsをクライアントとしてサーバ構築が可能として売り込むのであれば、今までできていた９８からのアクセスなどを廃止するのはメリットにはならないと思うのですが。
Tiger待ち、ですかね？

SMBを試してみましたが、XP Homeからは大丈夫でした。win98は手元に無いので、試せません。多分、2000も大丈夫だと思います。
win95,98は元々、文字化け等がありましたし、appleは、SMB接続の対象と考えていなかったようですが。
なお、米国では、10.3.6でもSMBでアクセスすれば大丈夫だったようです。

OSXserver10.3.7 内のロングファイルネーム共有フォルダにマックからのSMB接続を試していただけないでしょうか？
FinderのWindow内のネットワーク→Windowsワークグループ→OSXserver（Windowsワークグループ内でのサーバ設定必要）→ロングファイルネーム共有フォルダ
うちの場合、この操作で表示されるOSXserverの共有フォルダリスト内にロングファイルネーム共有フォルダはリストアップされません。
あ）XP,NT,2000からロングファイルネーム共有フォルダにアクセス可能
い）98からロングファイルネーム共有フォルダにアクセス不能
う）マックからのSMB接続でロングファイルネーム共有フォルダにアクセス不能
これではサーバの共有フォルダ設定の際に、XPなどからきちんとアクセスできるかどうかマックを使って確認できないのです。
（マックからのSMB接続は98レベルでのサポートなんですかね？）
と書いていながら、うちだけのトラブルだったら恥ずかしい限りです。

以下を試しました。
（１）MacOSX10.3.7からMacOSX Server10.3.7のpublicにSMBで接続。
（２）４０バイト長の名前のフォルダを作成し、内部に約４０バイト長のファイル名のファイルをクライアントからコピー。結果はＯＫ、逆にコピーしてもＯＫ
（３）MacOSX Server10.3.7のpublicにwindowsXP Professsionalからアクセス。フォルダ、ファイル共に、問題なく見える。ファイルを手元にコピーしても問題無し。
以上、支障ありませんでした。
>マックからのSMB接続は98レベルでのサポートなんですかね？
同じUnicodeを使用するのとsmbの認証の関係で、多分、NT,2000,XPのみ対応と思います。
kotanyanさんのトラブルは、ファイアーウオールかも知れません。windowsでMacOSXServerを信頼できるホストとして指定していますか。
また、MacOSXServerでパスワードサーバを使用していますか。私のところは、パスワードサーバの利用に気づくまでsmb接続は不可能でしたが、これに切り替えて、パスワードを再設定することで可能になりました。
なお、私のところも、今一、分かっていないところがあり、現状では、取りあえず繋がるからいいかといったレベルですので、最適解ではなく、他にもっと良い方法があるかも知れません。

> ９８からのアクセスなどを廃止するのはメリットにはならない
98 は使うな、ということでしょう。
セキュリティ、機能、問題はいっぱいあります。なぜそんなの使うの？といわれません？
> Tiger待ち、
ということはないと思います。
OSX (Server) の samba 機能は open source samba で実現しています。これは、open source ではこの方面の標準ソフトといってもいいくらい広く使われているものです。それが、サポートを止めたのなら、戻ることはないでしょう。98 をサポートするために、新たなプロジェクトが開始されるということはあり得ないと思います。

確かにPublicフォルダ内では問題なく表示されますね。
こちらの説明が不足していて申し訳ありません。
うちではデータは別ディスクで管理していますので、Publicフォルダでの共有は行っていないのです。
例）DATA HD に共有フォルダＡとか共有フォルダＢなどを作り、ワークグループマネージャーで共有設定し、マック及びWinで利用可能に設定
この共有フォルダＡやＢなどのように名前が全角５文字を超えていると、SMBでのアクセス可能なフォルダリストに出てこなくなるのです。
でワークグループマネージャーでWindowsからのアクセス設定でフォルダ名を「共有Ａ」などの短いフォルダ名に変更すると、SMBでのアクセス可能なフォルダリストに出てくるようになります。
このフォルダ内にロングファイルネームのファイルやフォルダを作成した場合はpublicフォルダ内と同じようにきちんと表示されます。
つまり共有設定されたフォルダの名前の長さがSMBアクセスに引っかかっていて、その内部のファイルについては問題ないようなのです。