Windows2000にVMwareをインストールして，CentOSを使っています．Windowsのフォルダをsambaで共有しているのですが，その共有フォルダで

>VMware

VMWare Workstation ?
VMWare Player
VMWare Server

http://www.atmarkit.co.jp/flinux/rensai/linuxtips/503usevmwfshare.html

>samba
確認：クライアントのWindowsとGUESTのCENT OSの
　　　　時間は、正確に一致していますか？(vmware tools等)

　txtファイルはCENTOS/Windowsいずれが生成
していますか？

>$ cp *.txt hatena/

cp操作はtxtファイルが出来た直後にしていませんか？
　

VMWare Serverです．
時間は同期の設定をしていますが，確認したら今はずれてます・・・
で，ファイルはWindowsでも，Linuxでも作ってます．
ファイル生成直後でなくても同じです．

よろしくお願いします．

やや状況が曖昧でよくわかりません。
・cp は Linux 上のコマンドを実行？
・samba で共有とは smbmount を利用ってこと？
・「ファイルの移動」とあるけど、cp だと移動じゃないよね？
・「残ってしまう」とは、コピーが行われないということ？
・それとも「移動されず残ってしまう」ということ？
・cp 実行直後の、echo $? の結果は？
具体的な現象がわかるログがあれば貼ってみては？

説明不足ですみません．
移動って書いたのは，mvの事を考えてました．
Windowsのフォルダ work を，WMware上のLinuxから /work にsmbmountでマウントしています．
その /work ディレクトリのサブディレクトリ内での事です．
例えば，????001.dat のファイルを001ディレクトリに移動させます．

$ mv ????001.dat 001/
$ echo $?
0
$ mv ????001.dat 001/
$ mv ????001.dat 001/
mv: cannot stat `????001.dat': そのようなファイルやディレクトリはありません
$ echo $?
1
$

となります．
一回目の mv では移動されないファイルがあるので，2回目の mv では警告メッセージが出ません．
2回目でも移動されない場合があります．

ちなみに，時計は30分で2分ほど進みます．
1時間毎に同期していたのを，5分毎にしても症状は同じです．
1秒に0.07秒狂うだけでも影響あるのでしょうか．

よろしくお願いします．

>Windowsのフォルダ work を，WMware上のLinuxから
>/work にsmbmountでマウントしています．

Windows /work <----- Linux(vmware) smbmount /work

症状:
1回で移動されない場合があります．


>ちなみに，時計は30分で2分ほど進みます．
>1秒に0.07秒狂うだけでも影響あるのでしょうか．

ファイル共有しているとかなり致命的です。

　http://pooh.gr.jp/item-2249.html
　http://webos-goodies.jp/archives/50179807.html
http://shin.moe-nifty.com/server/2006/05/virtual_server__8db6.html
http://akikaze.cocolog-nifty.com/blog/2006/04/vmwarecentosde_32a6.html

smbmount のオプション ttlを短くする。
　
http://www.samba.gr.jp/project/translation/2.2.5/manpages/smbmount.8.html

時計の狂いを修正して，3時間で±0.04秒まで改善しました．
が，やはり同様の症状が出ます．

smbmountのオプションを試してみます．

よろしくお願いします．

私の環境でやってみましたが、起きませんねぇ。再現すれば解決できると思いますが。
まっさらな状態から、smbmount、ディレクトリ作成、mv、不具合まで、一連の作業ログを省略なしで貼れませんか？
解決できる保証はないですが、少なくともこっちで同様の動作をさせてみますよ。
#時刻は関係ないと思いますよ。ネットワーク自体、遅延が大きい媒体ですし、mv に時刻情報が絡みようがないですから。

質問終了してしまいましたが，
とりあえず，smbmountのオプションを試しました．
が，やはりダメでした．

furutanianさん
再現して頂けると言う事で，ありがとうございます．
smbmountは，
mount -t smbfs -o username=taki,password=kyoka130!H,uid=taki,gid=vlbi,rw,iocharset=euc-jp,codepage=cp932,fmask=664,dmask=755,ttl=100000 //stgtaki/workspace /work

で，他は上記の通りです．

何かわかりましたら，よろしくお願い致します．

>mv に時刻情報が絡みようがないですから

Windows側でまずファイルを作成した内容は
smbmountしたLinux側のファイル参照するので
ディレクトリーをキャシュしているのでmv時参照
時ディレクトリーエントリーに不一致の可能性が発生します。

以下のような方法で動作確認をしてもらませんか？
　
1. Windows側でファイルの書込みをする前に
ready.datがファイルがある場合
ファイルが消えるまで書込みをしない

2. Windows側でファイルを作成する

3. Windows側でファイルの作成が終わったら
ready.datを作成

4. Linux側ではWindowsと共有している
　　ディレクトリーで複写する時以下の
　　Ｓｈｅｌｌを実行して複写してみてください。
　　可能なら3.のready.datを作成する前に
実行開始して開始に差異があるかをみてください。
　
smbmountのTTL
ローカルLANであればTTL　100秒は長すぎです。
コピー操作を人間がするなら100～500程度でも
　よいと思います。
　
==================================
#!/bin/bash
while true
do
if [ -f ready.dat ] ; then
echo "Ready to Copy "`date`
mv ????001.dat 001/
ls -l
rm -f ready.dat
echo "Copy End "`date`
break
fi
echo "Waiting Data "`date`
sleep 1
done
exit

通常のWindows/LinuxでもTTLが長い場合同様の
症状で発生しました。
TTL=100000だとWindows側で処理した内容が
Linux側に反映されるタイミングに100秒程度ずれ
が発生する。　
　
OSが正しく時計の管理が出来るようにする。
　→　既に対策済み
　
TTLを短くする。
　ためしにキャシュ時間をTTL=0 とか TTL=1　
に変更して動作させてみてください。
ただほとんどは問題がありませんが
微妙なタイミングで複写した場合はそれでも
ディレクトリー情報がずれる可能性はあります。

確実にするには前の ready.datのように
書き込みの終了タイミングを知らせる必要がある。

コメントありがとうございます．
時間がとれましたら，動作確認してみます．
すぐに出来なくてすみません．

ちょっと時間が取れたので，コメント頂いた事を試そうと思ったのですが，ready.dat というファイルはsambaで自動的に作られているファイルなのですか？
シェルを使ってファイルのコピー等する場合，自分で実行する場合は良いと思うのですが，既存のプログラムの中で知らないうちに実行されているファイルコピーが心配です．
sambaのTTLは1にしてみましたが，結果は変わらなかったです．
よろしくお願いします．

少しコメント。
この場合、ready.dat は、互いの進捗を認識するための用途に使っているもので、自動的に作られるわけじゃないですね。よって、おっしゃるとおり自分以外のファイルコピーは認識できません。
基本的な事ですが、Windows 側のプロセスがローカルに非同期に出力するファイルを、Linux 側で操作したいんですよね？　その場合、タイムラグを 0 にすることにどれほどの意味があるんでしょうか？　具体的にどんな使い方をしたいんでしょう？
ネットワークファイルシステムは、ネットワークという遅延の大きい媒体を経由するので、どの規格にも少なからずタイムラグがあります。また、ローカル同士であっても、A プロセスが書き出し中に、B プロセスが移動しようとするとややこしいことになります。
ネットワーク越しであるなしにかかわらず、複数のプロセスが共通のファイルを扱う場合は、どうしても何らかの制御が必要になります。そういう意味で、上述の ready.dat による方法はリーズナブルといえます。

コメントありがとうございます．
タイムラグについては，この質問の様な現象の解決になればと思ってやっております．質問の件については結果は変わりませんでしたが，良いアドバイスを聞けて満足しています．

それで，私が気になっているのは，

Windows上でVMwareのゲストOSとしてLinuxを使っている為，Linuxのディスク領域が少ない（増やせばいいのですが）ので，sambaでWindowsのディスク領域をファイル置き場として使っている状況
→　Linuxからsamba経由でファイル操作をすると，上記の様な現象が起きる
→　自分でコマンドラインで操作してるなら対処できるが，何らかのソフトウェアでsamba経由のWindowsディスク領域を一時ファイル置き場に指定していたりする場合困る

と言うことです．
この時，全てLinuxからの操作です．

質問の他にも，samba経由のWindows領域で，数千個のファイルを圧縮してあるファイルを解凍すると全て解凍されない（数が足りない）事があります．

この様な現象が起きるのはなぜか？対処のしかたは？と言うのが質問の意図です．
何か良いアドバイスをお願い致します．

>sambaのTTLは1にしてみましたが，

>指定していたりする場合困る

別のＯＳで共有している場合、如何なる
手段であれ関係なく、完了の同期処理は
必要従って、完了終了したらready.datを
作るバッチを手動で動かすなどすればよいだけ。

>？対処のしかたは
Windows側で完了とLinux側の認識の
タイミング認識は手動・プログラムに
関わらず同期方法は必須です。
ディスクをVMWAREに追加設定するか
NAS(バッファロー、IODATA)を買う

>結果は変わらなかったです．

考えられる理由はCPUパワー不足
Linux/Windowsに十分なCPU割当がないか、
非常にCPU負荷が高いソフトが動作している
　
VMWAREでディスク容量不足だけが問題
なのであれば追加のディスクを構成
すれば済む話。
VMWARE WORKSTATIONならGUIで可能
VMPLAYERなら手動又はVMX Builder等
のツールでも可能。
http://petruska.stardock.net/Software/VMware.html