『ファイルコピーした時のファイルの作成日時につきまして』のクチコミ掲示板

[今日は寒い。]

DS418Jをデータのバックアップを目的に購入したのですが、当方の環境では、次のような現象が発生して困っている状況です。

Robocopyでファイルコピーをすると、ファイルの作成日時が、コピーを実行した日時に戻るという症状です。

動作環境
PC:Windows 10 Pro 1903, IP:192.168.1.1
NAS:DS418J, IP:192.168.1.2
PCとNASはスイッチHUBを介して接続されている状況で、他の機器はHUBに接続されていません。
PCはOSをクリーンインストールして他にはアプリをインストールしていない状況です。
コピー元のフォルダ(C:\Temp)には1,000個のファイルを格納しておきます。
コピー先には、共有Testに、あらかじめフォルダ(Test01〜Test10)を準備しておきます。

実行するコマンド

1回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT
2回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\" /COPY:DAT
3回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test03\" /COPY:DAT
4回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
5回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test05\" /COPY:DAT
6回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test06\" /COPY:DAT
7回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test07\" /COPY:DAT
8回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test08\" /COPY:DAT
9回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test09\" /COPY:DAT
10回目のコピー
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test10\" /COPY:DAT

コピーを実行した直後のフォルダにあるファイルの作成日時をエクスプローラーで確認すると、
コピー元のファイル作成日付と同じになっているのですが、コピーを1回目から10回目ぐらいまで
続けると、1回目にコピーしたフォルダ(Test01)にあるファイルの作成日付が、コピーを実行した
日時に戻ってしまいます。
1回目にコピーしたフォルダ(Test01)のファイル作成日付が、元に戻とは限らず、他のフォルダの場合もあります。

他の環境では発生しないのか、使用方法がよくないのか、ご教示いただけますと助かります。

よろしくお願いいたします。

書込番号：23035107

[tanetty]

＞今日は寒い。さん

こんばんは。

当方、synologyを持っていないうえ、原因も見当がつきません。
このため、以下は役に立たない情報だと思うので、たいへん恐縮ですが。

＞Robocopyでファイルコピーをすると、
＞ファイルの作成日時が、コピーを実行した日時に戻る

＞コピー元のファイル作成日付と同じになっている
＞コピーを実行した日時に戻ってしまいます。

謎現象ですね…。 /COPYにTつけてるので、OKそうなものなのに。
コピー直後はOKなのに、しばらく経つとNGになってしまう…と。
しかも、NGになる場合とならない場合がある(＝再現性なし)…と。
Synologyが何かをきっかけに、勝手に書き換えちゃうのでしょうか？？？

原因がさっぱり思いつかないのですが、
次のことを試してみてはいかがでしょうか。
「もし治ったらもうけもん」ぐらいの気持ちの話になりますけども。

(a) robocopyのオプションを、念のためフルフルにしてみる。
robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /MIR /COPY:DATSOU /DCOPY:T

(b) 各コマンド間の実行に、時間を空けてみる。
robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /COPY:DAT
が完了してから10秒後に
robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\” /COPY:DAT
を実行….といった感じで。

(a)は「オプション足りない問題」か否かの切り分けに
(b)は「タイミング悪いかも問題」か否かの切り分けに
いちおうはなるかな…と

あと、/LOG:ファイル名 をつけてログを残して精査すると、
もしかしたら何かわかるかも？

以上、役に立たない情報ばかりで、失礼いたしました。m(_ _)m

書込番号：23035229

[とにかく暇な人]

＞今日は寒い。さん
多分、この問題は解決不能だと思いますので、例えば、7zipで
https://www.lisz-works.com/entry/compression-7zip-command
のようにしてコピーするフォルダーやファイルをアーカイブファイルにしてRobcopyでコピーすればよいのではないですか。
そうすれば、コピー時間が早くなるし、タイムスタンプの問題もなくなると思いますよ。
因みに、コピーで問題が発生するファイルは仮想マシンがらみのファイルではないですよね。

書込番号：23035261

[Excel]

念のために確認してもらいたいことがあるっす。

おんなじことを、NASへのコピーではなく、元ファイルとおんなじドライブ内の「別フォルダー」にした場合には、どうなるっすか？

書込番号：23035436

[galaxy1]

�@PC→NASでのrobocopyの話だと思いますが、どこかで
�ANAS→PC　の同期が走っていませんか
この製品の説明でいたるところに「PCやラップトップでデータ同期をリアルタイムで設定して、システムのクラッシュやランサムウェア攻撃からデータを守ります。 」との記載があり気になりました

書込番号：23035613

[LsLover]

『コピーを実行した直後のフォルダにあるファイルの作成日時をエクスプローラーで確認すると、
　コピー元のファイル作成日付と同じになっているのですが、コピーを1回目から10回目ぐらいまで
　続けると、1回目にコピーしたフォルダ(Test01)にあるファイルの作成日付が、コピーを実行した
　日時に戻ってしまいます。』

「コピーを実行した直後」：「コピー元のファイル作成日付と同じになっている」

しかし、

「コピーを1回目から10回目ぐらいまで続ける」：「コピーを実行した日時に戻ってしまいます。」

という状況のようですが、ある程度の時間経過後にファイル作成日付が書き換えられるということでしょうか?

書込番号：23035688

[たく0220]

＞今日は寒い。さん

こんにちは。
SynologyのNASは持っておりませんので確証はありませんが

ファイルシステムはext4だと思いますが、mount時のオプションで"user_xattr"ついているのかと
Sambaの設定で"store dos attributes = Yes"、つまり拡張属性が有効になっているのかが気になります。

Samba3ぐらいから作成日時も拡張属性で扱う範囲内かと思うので、その辺の確認からかな…

SSHが使えるなら、該当ファイルを"getfattr"コマンドで
"user.DOSATTRIB"の存在の確認。
なければ、どこかのタイミングかで消された可能性があるので
メーカーか代理店に聞くぐらいか、所有しているユーザーがいそうなSynology日本語フォーラムで聞くのが良いかもしれません。

書込番号：23036165

[今日は寒い。]

＞tanettyさん
このにちは。返信ありがとうございます。

ご提案の(a)(b)を実行してみました。

>(a) robocopyのオプションを、念のためフルフルにしてみる。
>robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /MIR /COPY:DATSOU /DCOPY:T

注意: セキュリティがコピーされない可能性があります - コピー先で固定 ACL がサポートされ ていない可能性があります。
と表示されてRobocopyが実行できませんでした。
このメッセージが何かわからないので後で調べようと思います。

>(b) 各コマンド間の実行に、時間を空けてみる。
>robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /COPY:DAT
>が完了してから10秒後に
>robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\” /COPY:DAT
>を実行….といった感じで。

コピー先を、"Test11"から"Test13"まで指定して約10秒間隔で実行しましたところ、
3003個のファイルにうち、154個のファイルが、コピーした日時になり、残りはコピー元の
ファイル作成日時のままになります。
コピーした日付時刻に戻ったファイルはすべて"Test12"フォルダの中にあります。

ログは、

合計 コピー済み スキップ 不一致 失敗 Extras
ディレクトリ: 1 0 1 0 0 0
ファイル: 1001 1001 0 0 0 0
バイト: 1000.00 m 1000.00 m 0 0 0 0
時刻: 0:00:31 0:00:31 0:00:00 0:00:00


速度: 33242750 バイト/秒
速度: 1902.165 MB/分
終了: 2019年11月10日 14:07:40

と、なっています。

よろしくお願いいたします。

書込番号：23038620

[今日は寒い。]

＞tanettyさん

こんにちは。

すいません。このにちは。になっていました。

訂正させていただきます。

書込番号：23038631

[今日は寒い。]

＞とにかく暇な人さん

こんにちは。返信ありがとうございます。

＞多分、この問題は解決不能だと思いますので、例えば、7zipで
＞https://www.lisz-works.com/entry/compression-7zip-command
＞のようにしてコピーするフォルダーやファイルをアーカイブファイルにしてRobcopyでコピーすればよいのではないですか。

このような使い方があったのですね。ありがとうございます。
コマンドプロンプトは、どうも苦手で、いつもは、CopyExtやBackupというフリーソフトを使用して、
USB外付けHDDにバックアップしていまして、この時は、作成日時が変更されることはないです。

何とか、この問題が解決できればと考えているのですが・・・。

＞因みに、コピーで問題が発生するファイルは仮想マシンがらみのファイルではないですよね。
仮想マシンがらみのファイルではないです。

よろしくお願いいたします。

書込番号：23038660

[今日は寒い。]

＞Excelさん
こんにちは。返信ありがとうございます。

＞おんなじことを、NASへのコピーではなく、元ファイルとおんなじドライブ内の「別フォルダー」にした場合には、どうなるっすか？

下記のコマンドで実行してみました。

robocopy "c:\temp\" "c:\temp1\" /COPY:DAT
robocopy "c:\temp\" "c:\temp2\" /COPY:DAT
robocopy "c:\temp\" "c:\temp3\" /COPY:DAT

コピー先の作成日時は、すべてのファイルがコピー元と同じになっていいます。

よろしくお願いいたします。

書込番号：23038674

[今日は寒い。]

＞galaxy1さん

こんにちは。返信ありがとうございます。

＞�ANAS→PC　の同期が走っていませんか

DS418Jには、パッケージセンターというのがありまして、そこには、
File StationとUniversal Searchがインストールされています。
この2個のパッケージは、アンインストールできないようです。

また、PCにも同期をとるようなソフトをインストールしていない状況です。

ですので、勝手に同期しないと思うのですが・・・。

よろしくお願いいたします。

書込番号：23038700

[今日は寒い。]

＞LsLoverさん

こんにちは。返信ありがとうございます。

＞という状況のようですが、ある程度の時間経過後にファイル作成日付が書き換えられるということでしょうか?

現状を報告します。

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test03\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test05\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test06\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test07\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test08\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test09\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test10\" /COPY:DAT

を実行すると、

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT
を実行した時点では、Test01内のファイルは、コピー先もコピー元も同じファイル作成日時で、
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
を実行した時点で、Test01内のファイルを確認すると、コピー先のファイル作成日時が、
コピーを実行したファイル日時になりま。

今までの実行結果ですと、

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test02\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test03\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test05\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test06\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test07\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test08\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test09\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test10\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test11\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test12\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test13\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test14\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test15\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test16\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test17\" /COPY:DAT
Robocopy "C:\Temp" "\\192.168.1.2\Test\Test18\" /COPY:DAT

を実行しますと、コピー先もコピー元も同じファイル作成日時のファイルは、

Test15フォルダ内に、1001個中　722個
Test16フォルダ内に、1001個中1001個
Test17フォルダ内に、1001個中1001個
Test18フォルダ内に、1001個中1001個

残りのファイルは、コピーを実行した日時に戻っています。

よろしくお願いいたします。

書込番号：23038752

[とにかく暇な人]

＞今日は寒い。さん
ファイルの日付が不正確になるのは、DS418jのファームか何かのバグだと思うので、Synologyに聞くしかないと思えてきたのですが、どうでしょうか。

書込番号：23038762

[今日は寒い。]

＞たく0220さん

こんにちは。返信ありがとうございます。

＞ファイルシステムはext4だと思いますが、mount時のオプションで"user_xattr"ついているのかと
＞Sambaの設定で"store dos attributes = Yes"、つまり拡張属性が有効になっているのかが気になります。

ファイルシステムの事はよくわからないのですが、とりあえず、SSHで接続してみました。

$cat /stc/fstabの実行結果を貼り付けます。(貼り付けて良いかどうかわかりませんが。)

none /proc proc defaults 0 0
/dev/root / ext4 defaults 1 1
/dev/vg1000/lv /volume1 ext4 usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl,relatime 0 0

"getfattr"コマンドは、
-sh: getfattr: command not found
で使えないようです。

$cat /etc/samba/smb.confの実行結果を貼り付けます。(これも貼り付けて良いかどうかわかりませんが。)

[global]
printcap name=cups
winbind enum groups=yes
include=/var/tmp/nginx/smb.netbios.aliases.conf
min protocol=SMB2
security=user
local master=no
realm=*
passdb backend=smbpasswd
printing=cups
max protocol=SMB3
winbind enum users=yes
load printers=yes
workgroup=WORKGROUP

これで何か分かりますでしょうか。他に調べ方がありましたら、ご教示をお願いいたします。

＞Synology日本語フォーラムで聞くのが良いかもしれません。
Synology日本語フォーラムというのがあるのですね。ありがとうございます。

よろしくお願いいたします。

書込番号：23038834

[Chubou]

一つ確認したい点があります。

ファイルの「作成日時」が書き換わると言われておりますが、ファイルのタイムスタンプには色々なものがあります。
「日付時刻」「作成日時」「更新日時」「撮影日時」などです。（「撮影日時」は画像ファイル、ピクチャ・フォルダ等の場合のみ該当）

エクスプローラーの表示設定によって、タイムスタンプの表示内容や表示の意味が変わったりもします。
エクスプローラーの「表示」タブ - 「詳細」の表示にした後、「列の追加」アイコンをクリックして、表示項目にチェックを入れることで表示する「日時」を選ぶことができます（添付画面参照）。
添付画面では、「日付時刻」「作成日時」「更新日時」にチェックを入れて、表示している状態です。

そこで、スレ主さんに質問です。
スレ主さんは「作成日時が変化する」と言われていますが、変化するのは本当に「作成日時」なのでしょうか？

変化するのが本当に「作成日時」であれば、原因を想像しにくいのですが、もし、変化するのが「作成日時」ではなく「更新日時」であれば、状況から考えて DS418J 上で何らかの自動更新処理が働いているのではないかと疑うことができます。

書込番号：23038879

[たく0220]

＞今日は寒い。さん

確認と情報ありがとうございます。

現象を伺っているとキャッシュが一回りして内容が変わってしまったような現象ですね。
PCを一度再起動してみた場合ではどうですか？
作成日時が元ファイルと同じファイルが残っていますか？

＞$cat /stc/fstabの実行結果を貼り付けます。(貼り付けて良いかどうかわかりませんが。)
mount での確認の方が良いかもしれません。

QNAP TS-231Pの例(該当箇所以外は省略)
# mount
/dev/mapper/cachedev1 on /share/CACHEDEV1_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,d

"getfattr"は使えませんでしたか…
お手数かけました。残念。


＞$cat /etc/samba/smb.confの実行結果を貼り付けます。(これも貼り付けて良いかどうかわかりませんが。)

Sambaの"testparm"コマンドに詳細(-v)と"grep"コマンドをパイプ(|)で連携させて確認してみてください。
何も表示されない場合は、設定がされてない可能性があります。

・"testparm"コマンド使えるか確認方法
which testparm

[実行例]
# which testparm
/usr/bin/testparm

・testparm
("Press enter to see a dump of your service definitions"と表示されたらEnterを押す)
testparm -v | grep "store dos attributes"

[実行例]
# testparm -v | grep "store dos attributes"
Load smb config files from /etc/config/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "null passwords" option is deprecated
Processing section "[Multimedia]"
Processing section "[Download]"
*** 省 略 ***

EDEV1_DATA/.samba/state should have permissions 0755 for browsing to work

Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

store dos attributes = Yes


＞注意: セキュリティがコピーされない可能性があります - コピー先で固定 ACL がサポートされ ていない可能性があります。

Synologyサポートセンター : 共有フォルダに権限を割り当てる
https://www.synology.com/ja-jp/knowledgebase/DSM/help/DSM/AdminCenter/file_share_privilege#t2
の「Windows ACL 権限のカスタマイズ」を確認してみてください。

私のNASでは面倒なので拡張ACLはOFFにしてます ^^;

以下も参考になるかと思います。
http://www.nslabs.jp/samba-windows-acl.rhtml

書込番号：23038894

[今日は寒い。]

＞とにかく暇な人さん

こんにちは。返信ありがとうございます。

＞ファイルの日付が不正確になるのは、DS418jのファームか何かのバグだと思うので、Synologyに聞くしかないと思えてきたのですが、どうでしょうか。

実のところ、Synologyのサポートには、10月16日から10回以上にわたり、やり取りをしていまして、Synologyから要求で、パケットキャプチャのデータを提供したり、デスクトップの共用の提供をしたりしてきました。

しかしながら、何回も訴えましたが、Synokogy側は、当方のPCの問題であって、DS418Jには、問題ないとの回答なのです。

ですので、Synokogy側に「皆さんに聞いてみます。」と伝えた上で、皆さんに状況を、ご質問させていただいた次第です。

DS418Jは2台所有していまして、1台はデータが保存されていて、作成日時が化けてしまって、どこにもバックアップもなく、作成日時を戻せなくて、大変困っています。あと1台は、データを移動させて、検証している状況です。

よろしくお願いいたします。

書込番号：23038903

[たく0220]

＞今日は寒い。さん

補足ですが"stat"というコマンドでファイルを確認することもできます。
Windows(NTFS)の作成日時にあたるのは"Birth:"という項目になるのですが
私のでは対応してないのか、表示されてません。

# stat 1572727499.zip
File: "1572727499.zip"
Size: 7767 Blocks: 24 IO Block: 4096 regular file
Device: fc00h/64512d Inode: 2168 Links: 1
Access: (0666/-rw-rw-rw-) Uid: ( 0/ admin) Gid: ( 0/administrators)
Access: 2019-11-10 15:41:30.000000000
Modify: 2019-11-03 06:18:20.000000000
Change: 2019-11-03 06:25:55.000000000

書込番号：23038930

[とにかく暇な人]

＞今日は寒い。さん
本問題の再現環境を作って、Synologyに送って実行して確認してもらったらどうですか。

書込番号：23038943

[今日は寒い。]

Test15フォルダ内の状況

＞Chubouさん

こんにちは。返信ありがとうございます。

＞スレ主さんは「作成日時が変化する」と言われていますが、変化するのは本当に「作成日時」なのでしょうか？

「作成日時」になります。フォルダ内の状況を添付致します。ご確認いただけますでしょうか。

更新日付は変化していません。

よろしくお願いいたします。

書込番号：23038963

[今日は寒い。]

＞たく0220さん

こんにちは。返信ありがとうございます。

＞PCを一度再起動してみた場合ではどうですか？
＞作成日時が元ファイルと同じファイルが残っていますか？

PCを再起動してみました。結果は同じで、コピー先もコピー元も同じファイル作成日時のファイルは、

Test15フォルダ内に、1001個中　722個
Test16フォルダ内に、1001個中1001個
Test17フォルダ内に、1001個中1001個
Test18フォルダ内に、1001個中1001個

となっています。

＞mount での確認の方が良いかもしれません。

#mountを実行しましたので結果を貼り付けます。
/dev/mapper/vg1000-lv on /volume1 type ext4 (rw,relatime,synoacl,stripe=48,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)


＞Sambaの"testparm"コマンドに詳細(-v)と"grep"コマンドをパイプ(|)で連携させて確認してみてください。
testparmコマンドを実行しましたので結果を貼り付けます。

# testparm -v | grep "store dos attributes"
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Can't find include file /var/tmp/nginx/smb.netbios.aliases.conf
Processing section "[Test]"
/etc/samba/smb.reserved.conf not found
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

store dos attributes = No


＞Synologyサポートセンター : 共有フォルダに権限を割り当てる
＞以下も参考になるかと思います。

サイトをご提供いただき、ありがとうございます。勉強します。

よろしくお願いいたします。

書込番号：23039057

[tanetty]

＞今日は寒い。さん

こんばんは。
さっそく実験してくださったのですね。
誠にありがとうございます。
お手数かけ、申し訳ありませんでした。



�@ フルフル時のセキュリティエラーについて

「セキュリティがコピーされない可能性があります」については、
コマンドプロンプトを「管理者として実行」なさってないようでしたら、
お試しいただく価値はあるかと思います。

https://www.adminweb.jp/command/ini/index12.html

それでもダメなら、以降はCOPYの後ろのSOU部分は、削除してください。
こんな感じで(↓)。
robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /MIR /COPY:DAT /DCOPY:T

※Windows上で持っていた権限情報をコピーするのが、SとOとUです。
　Linux上で意味がなければ、スルーしてくれるかな？思っていたのですが、
　もしかしたら違うのかもしれませんね。スミマセン。



�A 時間をおいたときでもダメな件

＞コピー先を、"Test11"から"Test13"まで指定して約10秒間隔で実行しましたところ、
＞3003個のファイルにうち、154個のファイルが、コピーした日時になり、
＞残りはコピー元のファイル作成日時のままになります。

「一部がコピーした日時」になってしまっている状態から、
何回か/MIRつきで走らせるとどうなるでしょうか。

こんな感じで(↓)
robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\” /MIR /COPY:DATSOU /DCOPY:T

/MIRがついていると、完全に差分コピーとなります。つまり、
・タイムスタンプが同じファイルは、スルーします。
・タイムスタンプが異なるファイルのみ、上書きしてくれます。
・差分のみの処理なので、２回目以降は初回に比べ、格段に早く終了します。

/MIRつきでくりかえし実行して、もしうまくいくのなら、
解決策にはなりませんが、回避策にはなるかと思います。
robocopyを/MIRつきで数回くりかえすバッチファイルをつくっておけば、
NGだったファイルだけ再実行してくれますので。



�B アンチウィルス容疑者説

あと、「アンチウィルス系が悪さしてないか？」ということも、疑っています。
もしPC側・Synology側に、アンチウィルスが入っていたら、ですが。
それぞれ一時的に停止して、どうなるか？
を試してみると、その切り分けになるかと思います。

書込番号：23039094

[今日は寒い。]

＞とにかく暇な人さん

こんばんは。返信ありがとうございます。

＞本問題の再現環境を作って、Synologyに送って実行して確認してもらったらどうですか。

再現環境を作って、Synologyからリモートデスクトップでアクセスしてもらって確認してもらいました。

Synology側の確認は、

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test01\" /COPY:DAT

だけを実行して、「問題なし」の判断です。

Robocopy "C:\Temp" "\\192.168.1.2\Test\Test04\" /COPY:DAT
を実行した時点で、Test01内のファイルを確認すると、コピー先のファイル作成日時が、
コピーを実行したファイル日時になる。

というのは、何度指摘しても確認しようとしません。

これが現状です。

本問題で、10回以上Synologyとのやり取りしており、もう疲れてきました。
(愚痴ってしまいました。すみません。)

よろしくお願いいたします。

書込番号：23039183

[Chubou]

今日は寒い。さん

> 「作成日時」になります。フォルダ内の状況を添付致します。ご確認いただけますでしょうか。
> 更新日付は変化していません。

なるほど。
「更新日時」は変わっていない。「作成日時」が変わっているのですね。
2019/11/10 15:03 がコピー作業を行った日時ということですか。

結果として、「更新日時」より「作成日時」の方が新しい日付になっていますね。 これは、確かにおかしいですね。
ファイルシステムに何か問題がありそうです。
可能性としては、やはり DS418j のファイルシステムに問題が…。

書込番号：23039206

[LsLover]

『コピー先もコピー元も同じファイル作成日時のファイルは、

　Test15フォルダ内に、1001個中　722個
　Test16フォルダ内に、1001個中1001個
　Test17フォルダ内に、1001個中1001個
　Test18フォルダ内に、1001個中1001個

　残りのファイルは、コピーを実行した日時に戻っています。』

「Test15フォルダ内に、1001個中　722個」以外とTest1[8-10]フォルダ内のファイルでコピーを実行した日時に戻るようですね。
規則性が絞りにくいですね。

改善するか分かりませんが、以下を試しては如何でしょうか?

当方では、以下のようなパラメータでローカルディスクのディレクトリをNASの共有フォルダにバックアップしています。
ローカルディスクのディレクトリ内の更新されたファイルのみNASの共有フォルダにコピーします。初回のみ、ローカルディスクのディレクトリ内のすべてのファイルをNASの共有フォルダにコピーします。

robocopy.exe /E /MIR /NFL /NDL /NP C:\[ローカルディレクトリ] \\[NASのIPアドレス]\[共有フォルダ]

書込番号：23039225

[たく0220]

＞今日は寒い。さん

確認と情報ありがとうございます。

結果を見ると、従来の拡張属性での方法ではなく
Synology独自の方法を取られてる感じはします。

調べてる時に下記Qiitaの記事がヒットしました。
Qiita : Mac の Go で birth time を取得する
https://qiita.com/hiokidaichi/items/26890e7da566cb3a4121

「Mac 以外では・・ ?」の項目でSynologyのNASからcrtime(作成日時)を参照できたそうです。
ということは、ext4のinodeにcrtime(作成日時)を記録していると考えられます。

ただし、ext4はcrtime(作成日時)を元々は扱っていませんでした。
ですのでまだSambaや他のソフトウェアとの連携に問題が残っている可能性は十分に考えられます。

Windowsのエクスプローラー上だけcrtime(作成日時)が読めない場合があるか
Sambaからの書き込み時にcrtime(作成日時)が反映されない場合があるのどちらかだと思います。

まずはSSHで現状ファイルがどのように記録されているかも確認された方が良いかと思います。

# ls -i foo
のところから(fooはファイル名)でinodeの番号がわかります。

# debugfs -R "stat <27204>" /dev/md0

"stat <27204>" は先ほどのinodeの番号を<>内に
/dev/md0 は /dev/mapper/vg1000-lv
に変更して試してみてはどうでしょうか。

書込番号：23039275

[今日は寒い。]

コピー元	再起動前	再起動後

＞みなさま

たくさんのご返信ありがとうございます。

みなさまからいただきました情報をもとに、当方で色々と確認致しました。
新たに判明しました状況を報告致します。

動作環境は当方が書き込みをさせていただいた時点と同じになります。
ウィルス対策ソフトは別途インストールしておらずDefenderが動作しています。
DS418Jにはウイルス対策パッケージをインストールしていない状況です。

次の手順で操作しますと、全てのファイルがコピーした日時に戻りました。

1.Robocopyコマンドでコピーする。
robocopy "c:\temp\" "\\192.168.1.2\Test\Test20\" /MIR /COPY:DAT /DCOPY:T

2.ファイルの作成日時を確認する。
→コピー元のファイル作成日時と同じになっている。

3.DS418Jを再起動する。

4.1で実行したファイルの作成日時を確認する。
→\\192.168.1.2\Test\Test20フォルダ内のすべてのファイルがコピーを実行した日時に戻る。


次のように確認しました。

1.あらかじめ作成日時がコピーを実行した日時のファイル情報を確認。
(とりあえず1つだけ)

\\192.168.1.2\Test\Test15フォルダ内の11.datファイル
作成日時:2019-11-10 15:03 (エクスプローラー上の作成日時)

#ls -i 11.dat
129906413 11.dat

# debugfs -R "stat <129906413>" /dev/mapper/vg1000-lv
debugfs 1.42.6 (21-Sep-2012)
Inode: 129906413 Type: regular Mode: 0777 Flags: 0x80000
Generation: 271770684 Version: 0x00000000:00000000
User: 1024 Group: 100 Size: 1048576
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 2048
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5dc7a81e:3eeac980 -- Sun Nov 10 15:03:10 2019
atime: 0x5dc2dff0:00000000 -- Thu Nov 7 00:00:00 2019
mtime: 0x5dbb0718:00000000 -- Fri Nov 1 01:08:56 2019
crtime: 0x5dc7a81e:37c3b44c -- Sun Nov 10 15:03:10 2019
Size of extra inode fields: 36
Extended attributes stored in inode body:
archive_version = "52 25 01 00 01 00 00 00 " (8)
EXTENTS:
(0-255):3415296-3415551

2.Robocpyを実行してコピーを実行
robocopy "c:\temp\" "\\192.168.1.2\Test\Test20\" /MIR /COPY:DAT /DCOPY:T

3.あらたにコピーしたファイルの情報を確認。
(とりあえず1つだけ)

\\192.168.1.2\Test\Test20フォルダ内の1.datファイル
作成日時:2019/11/01 1:08 (エクスプローラー上の作成日時)
→コピー元のファイル作成日付と同じ。

# ls -i 1.dat
129892355 1.dat

debugfs -R "stat <129892355>" /dev/mapper/vg1000-lv
debugfs 1.42.6 (21-Sep-2012)
Inode: 129892355 Type: regular Mode: 0777 Flags: 0x80000
Generation: 3144990274 Version: 0x00000000:00000000
User: 1024 Group: 100 Size: 1048576
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 2048
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5dc8e45c:ac7928c0 -- Mon Nov 11 13:32:28 2019
atime: 0x5dc2dff0:00000000 -- Thu Nov 7 00:00:00 2019
mtime: 0x5dbb0716:00000000 -- Fri Nov 1 01:08:54 2019
crtime: 0x5dc8e45c:a08d5ad4 -- Mon Nov 11 13:32:28 2019
Size of extra inode fields: 36
Extended attributes stored in inode body:
archive_version = "52 25 01 00 01 00 00 00 " (8)
EXTENTS:
(0-255):68608-68863

4.DiskStation Manager (DSM)上で他のファイルの作成日時がわかるように画面コピーする

5.DS418Jを再起動
→DiskStation Managerから[再起動]を実行

6.1で実行したファイルの作成日時を確認

\\192.168.1.2\Test\Test20フォルダ内の1.datファイル
作成日時:2019/11/11 13:32 (エクスプローラー上の作成日時)
→コピーを実行した日時に戻りました。

\\192.168.1.2\Test\Test15フォルダ内の11.datファイル
作成日時:2019-11-10 15:03 (エクスプローラー上の作成日時)
→コピーを実行した日時のまま

7.DiskStation Manager (DSM)上でファイルの作成日時がわかるように画面コピーする

以上になります。

画面コピーを添付しておきます。


この症状は、DS418Jの不具合のように思えてなりません。
もしかしたら、当方だけではないような気もします。
SynologyのNAS所有者の方(DS418J以外の機種でもいいです)で、
同じ症状になるか試していただけますと幸いです。

よろしくお願いいたします。

書込番号：23040621

[今日は寒い。]

＞みなさま

もうひとつ情報を、ご提供させていただきます。

それは、DS418Jに搭載しているHDDになります。

当方、Seagate ST4000VN008 - 2DR166を4台搭載していて、
(Synologyのサイトで、現状、テストおよび検証済みHDDとなります。)

RAIDタイプ : Synology Hybrid RAID(SHR
ストレージプール : 1
ステータス : 正常

となっています。

よろしくお願いいたします。

書込番号：23040642

[たく0220]

＞今日は寒い。さん

こんばんは。確認ご苦労様です。

画像なのですが、再起動前と再起動後が同じ画像のように見えます
アップロード時に間違われてませんか？


＞3.あらたにコピーしたファイルの情報を確認。

で"debugfs"コマンドで確認された作成日時(crtime)ですが

＞ crtime: 0x5dc8e45c:a08d5ad4 -- Mon Nov 11 13:32:28 2019

ですので、"2019/11/11 13:32:28" がコピーされたファイル(1.dat)に記録されている作成日時です。

＞作成日時:2019/11/01 1:08 (エクスプローラー上の作成日時)
＞→コピー元のファイル作成日付と同じ。
との事でしたので、この時点ではDSMの"File Station"上では正常(コピー元と同じ)であって
DS418Jの再起動後に異常(コピーを実行した日時に)に戻ったという事ですか？


＞この症状は、DS418Jの不具合のように思えてなりません。

ext4でcrtimeを変更出来るメソッドは今のところ無いと個人的に認識していたので
Sambaの設定見たときは、出来るようになったの？と疑問があったのですが…
WindowsとLinuxでは作成日時に対する扱い(考え方)が違うので、その違いをサポートが理解してない可能性もあり、
不具合というより、仕様(元々出来ない)という事もありえそうです。

書込番号：23039057で、コピー先もコピー元も同じファイル作成日時のファイルがあったと思いますが
DS418Jの再起動後ですが、エクスプローラー上で作成日時の変化はありましたか？

書込番号：23040927

[今日は寒い。]

再起動前	再起動後

＞たく0220さん

こんばんは。返信ありがとうございます。

＞画像なのですが、再起動前と再起動後が同じ画像のように見えます
＞アップロード時に間違われてませんか？

ご確認ありがとうございます。確かに間違っておりました。
再度アップロードいたします。

よろしくお願いいたします。

書込番号：23041058

[とにかく暇な人]

＞今日は寒い。さん
DiskStation DS418jがLinixベースで動作していれば、作成日時をRobocopyでコピーするのは不可能だから、ある意味では、作成日時がコピー日時と同じになるのは仕様と考えるしかないですよね。
ただし、作成日時がコピーされたように見えるのは、明らかなバグなので、この事はSynologyにバグとして認識してもらわなければならないですよね。
そこで画像を見て気になったのですが、WindowsのExplorerとFile Staitionで作成日を見た場合に差異はないのでしょうか。
もし、Explorerで見て作成日時が全てコピー日時と等しければ、DiskStation DS418jのバグではなくて、File Staitionのバグという事になると思いますので、どうか確認をお願いします。

書込番号：23041141

[今日は寒い。]

＞たく0220さん

こんばんは。返信ありがとうございます。

＞＞ crtime: 0x5dc8e45c:a08d5ad4 -- Mon Nov 11 13:32:28 2019
＞ですので、"2019/11/11 13:32:28" がコピーされたファイル(1.dat)に記録されている作成日時です。

なるほど、ご教示ありがとうございます。

＞＞作成日時:2019/11/01 1:08 (エクスプローラー上の作成日時)
＞＞→コピー元のファイル作成日付と同じ。
＞との事でしたので、この時点ではDSMの"File Station"上では正常(コピー元と同じ)であって
＞DS418Jの再起動後に異常(コピーを実行した日時に)に戻ったという事ですか？

そうなります。

＞ext4でcrtimeを変更出来るメソッドは今のところ無いと個人的に認識していたので
＞Sambaの設定見たときは、出来るようになったの？と疑問があったのですが…
＞WindowsとLinuxでは作成日時に対する扱い(考え方)が違うので、

なるほど、ご教示ありがとうございます。勉強になります。

＞不具合というより、仕様(元々出来ない)という事もありえそうです。
Synologyサポートには「仕様ですか？」と問い合わせましたが、ファイル作成日時はSynology側で異常は認められず、当方のPC等が原因との見解です。
ですので、仕様(元々出来ない)という事はないように思います。
購入した当時は、異常はなかったような気もします。(今回の症状に気が付いていなかっただけ？かも。)

＞書込番号：23039057で、コピー先もコピー元も同じファイル作成日時のファイルがあったと思いますが
＞DS418Jの再起動後ですが、エクスプローラー上で作成日時の変化はありましたか？

DS418Jの再起動後、作成日時がコピー元と同じファイルは、20,020個中0個で、コピー先もコピー元も同じファイル作成日時のファイルは一つもありません。

よろしくお願いいたします。

書込番号：23041170

[今日は寒い。]

再起動前	再起動後

＞とにかく暇な人さん

こんばんは。返信ありがとうございます。

＞そこで画像を見て気になったのですが、WindowsのExplorerとFile Staitionで作成日を見た場合に差異はないのでしょうか。
＞もし、Explorerで見て作成日時が全てコピー日時と等しければ、DiskStation DS418jのバグではなくて、File Staitionのバグという事になると思いますので、どうか確認をお願いします。

次のコマンドを実行ました。

1.robocopy "c:\temp\" "\\192.168.1.2\Test\Test22\" /MIR /COPY:DAT /DCOPY:T
2.エクスプローラーの画面コピー
3.DS418Jの再起動
4.エクスプローラーの画面コピー

画面コピーを添付いたします。

ご確認いただけますと助かります。

＞ただし、作成日時がコピーされたように見えるのは、明らかなバグなので、この事はSynologyにバグとして認識してもらわなければならないですよね。
ありがとうございます。うまくSynologyに伝わればよいのですが・・・。当方だけではなんともならないような気も・・・。

よろしくお願いいたします。

書込番号：23041269

[とにかく暇な人]

＞今日は寒い。さん
ご報告ありがとうございました。
DiskStation DS418j側のバグであろうという事ははっきりしたと思いますが、Sambaのバグなり仕様なので、Synologyとしてはどうする事も出来ないという可能性も有るかもしれないですね。
という事で、私としては、作成日時を頼りにした管理をやめるか、私が書込番号:23035261で提案したような方法を採用するか、作成日時をファイル名に含めるようにしたほうが良いのではないかと思いました。

書込番号：23041341

[たく0220]

＞今日は寒い。さん

確認ありがとうございます。

＞Synologyサポートには「仕様ですか？」と問い合わせましたが、ファイル作成日時はSynology側で異常は認められず、当方のPC等が原因との見解です。

Synology側はRobocopyで正常を確認してるという事ですか…
けど具体的な原因については教えてくれなかったのですね。


＞購入した当時は、異常はなかったような気もします。(今回の症状に気が付いていなかっただけ？かも。)

ファームウェア(DSM)のバージョンをその頃まで安全に戻せるのなら良いのですが
それで問題点を指摘してもSynologyのサポートが認めてくれるか不明ですね。


＞DS418Jの再起動後、作成日時がコピー元と同じファイルは、20,020個中0個で、コピー先もコピー元も同じファイル作成日時のファイルは一つもありません。

ディスクキャッシュか何かしらのキャッシュがDS418J側に残っていて、作成日時が正しく見えてるのかもしれませんね。
残念ながらこれ以上は情報を持ってませんので、同様な症状を確認しているユーザーが現れるのを待つぐらいですね。

あとは、相談してなかったら日本の代理店に相談してみるぐらいかな。

書込番号：23041413

[tanetty]

＞今日は寒い。さん

本件、すでに多大な労力・時間を費やしてらっしゃるとのこと。
心理的負担も、いかばかりのことでしょう。
心中お察しいたします。m(_ _)m

Synologyを再起動すると、ぜんぶコピー日時になっちゃうって...。
とすると、もうあきらかに悪いのはSynologyですよね。

本件、Synologyの「仕様」なのか、「不具合」なのか、不明です。
しかし、いずれにせよ原因は、Synolgy側にある。PC側にはない。
このことは、各種実験から、ほぼ確実だといえそうです。



以下、外野の戯言で恐縮ですが。

今後、今日は寒い。さんがSynologyに対して、
どういう方針でご対応なさっていくおつもりなのか、
検討するよいタイミングなのではないか、と愚考いたします。

というのは、今日は寒い。さんが
・これまで費やした労力・時間・心理的負担
・これから費やすであろう労力・時間・心理的負担
に、みあう効果が得られるのか、
どうにも先が見えない状況だからです。

一般に、ユーザ側で「あれ？」と思う症状をメーカーに問い合わせたとき、
メーカー側では、次の順に行動をとるかと思います。

＜メーカー側の行動＞
�@ 症状の再現性を認める。
�A 再現性を認めた場合、不具合か仕様か判定する。
�B 不具合の場合、原因・解決策を探る。
�C 解決策がある場合、実施するか否か検討する。
�D 解決策を実施する。

本件では現状、�@にすら到達していません。
これから仮に、今日は寒い。さんが、
さらに苦労に苦労をかさね、�@を完了させたとしても、
�Dまでの道のりは遠そうです。

という状況を踏まえたうえで…
方向性は３つあるかと。

(a) 「どうせ�Dまでは無理だし、OKだとして時間がかかりそうだ」
という見通しのもと、Synologyとのやりとりを中止するのも、アリだと思います。

(b) 「�Dまでは無理でも、せめて�@までは完了しないと気が済まない」
という方向性も、めっちゃ理解できます。

(c) 「いやいや、�Dまで、倒れるところまでいくんだ！」
これも、よーくわかります。

私だったら、どうするかなー。
なんとなくですが、(c)のような気がします。

その際には、こんな論理展開にするかと。
「こっちでこれだけ詳細かつ緻密に実験して、
　Synlogyがクロ、PCがシロである証拠を、これだけそろえました。
　PCがクロだと主張したいなら、
　Synologyがシロである証拠を、
　今度はそちら側でそろえる番でしょ？
　違いますか？」

この論理展開をする場合、「詳細かつ緻密に実験」の資料を、
ぐうの音もでないほどしっかり記載する必要がありますが。
メーカーと戦うのは、やっぱり骨が折れますね…。
とすると、(a)の方向性もあるけど、悩むー。

以上、単なる戯言で失礼いたしました。

書込番号：23043523

[今日は寒い。]

＞みなさま

たくさんのご返信ありがとうございます。

＞とにかく暇な人さん

＞DiskStation DS418j側のバグであろうという事ははっきりしたと思いますが、Sambaのバグなり仕様なので、Synologyとしてはどうする事も出来ないという可能性も有るかもしれないですね。

他のメーカーや他の機種はどうなっているのか、疑問がわくところです。NetgearのLinuxベースNASは作成日付が消えてしまったりしないのですが・・・。

＞作成日時を頼りにした管理をやめるか、私が書込番号:23035261で提案したような方法を採用するか、作成日時をファイル名に含めるようにしたほうが良いのではないかと思いました。

当方、写真やビデオなどのデータについて、ファイル作成日時を頼りにした管理をしていました。既に作成日時を消失していますので、撮影時刻などの詳細を取り戻すこともできず残念です。これからのデータについては、ご提案のありましたように管理方法を変えていく必要があるかもしれないですね。


＞たく0220さん

＞ディスクキャッシュか何かしらのキャッシュがDS418J側に残っていて、作成日時が正しく見えてるのかもしれませんね。
＞残念ながらこれ以上は情報を持ってませんので、同様な症状を確認しているユーザーが現れるのを待つぐらいですね。

たく0220さんの、「birth time を取得する」で、作成日時が正しく見えていたファイルも、コピーを実行し日時になっていましたので、キャッシュかな？と気づくことができました。いろいろとご教示いただきまして、ありがとうございます。


＞tanettyさん

途中で、このNASをゴミにしようかとも考えたり、iSCSIで接続したらなとんかなるかな？と考えたりしました。せっかく購入したものなので、NAS本来の使い方？ができれば(他のメーカーのNASができているのですから)良いのですが、果たしてメーカーがどこまで対応してくれるかは不明です。できれば直してほしいのですが・・・。直してもらえなかったら、やはりこのNASはゴミの運命か？。いろいろ考えるところです。とりあえずメーカーには、再起動で作成日時がコピー日時に戻る症状を伝えたので、どのように対応してくれるのかを待ってみたいと思います。

メーカーからの回答がありましたら、顛末として報告させていただければと思います。

よろしくお願いいたします。

書込番号：23045746

[tanetty]

今日は寒い。さん、こんばんは。

＞再起動で作成日時がコピー日時に戻る症状を伝えたので、どのように対応してくれるのかを待ってみたいと思います。
＞メーカーからの回答がありましたら、顛末として報告させていただければと思います。

ありがとうございます。m(_ _)m
本当にたいへんそうですね…。
うまいことSynlogyが対応してくれることを、心より祈っております。



＞他のメーカーや他の機種はどうなっているのか、疑問がわくところです。

以下の情報が参考になるかどうか、甚だ疑問ですが、
何かの足しに少しでもなれば…との思いから、念のため報告させていただきます。

次のとおり、コピー元・コピー先・ツール・症状いずれも異なりますが、
私も「作成日時がコピーされない」件で悩んでいたことがあります。

今日は寒い。さんは
「Windowsから」「Synologyへ」「Robocopyで」
「コピー前半のファイルの一部が、コピー後半にコピー日時に戻ってしまうことがある」
「NAS再起動で、すべてコピー日時になってしまう」

私は、
「Macから」「QNAPへ」「rsyncで」
「作成日時がコピーされない」

このとき、どうしたか？　rsyncを
「Mac標準で組み込まれているもの」から
「外部からインストールしたもの」に
変更したら、作成日時が正常にコピーされるようになりました。
(現在も無事に運用できております)

詳しくは、下記リンク・下記情報をご参照ください。

＜作成日時等を維持したまま、まとめてファイルをコピーするには？ 2019/07/02 ＞
https://bbs.kakaku.com/bbs/K0000925629/SortID=22771912/#tab

＜実験環境・実験結果の補足＞
・コピー元は、FAT32のmicroSD内にある、動画または写真のファイル群。
・当該ファイル群は、プラネックスの監視カメラがmicroSD内に作成したもの。
・当該ファイル群には作成日時が、ファイル名内にも映像内にも埋め込まれている。
・Macは、MacBook Pro 13 (2018)。
・MacOSは、2019/7/2当時の最新版。(たぶんMojave)
・NASは、QNAP TS-431P。
・QNAPのファームウェアは、2019/7/2当時の最新版。
・QNAPは、HDDx4本のRAID5。
・作成日時は、MacのFinder上から確認。
・NASを再起動しても、作成日時は変わらない。

書込番号：23045887

[今日は寒い。]

＞tanettyさん

「rsync」でご苦労なさったのですね。お疲れ様です。また、動作検証をしていただきまして、ありがとうございます。
当方は、Windows環境ですので、「rsync」をどうしたらよいか、よくわかっていません。調査してみます。

＞みなさま

当方の知人が、Synologyの「DS218+」を所有されていたので、今回の症状について、検証していただきました。
この場をお借りして、お礼致します。

その検証結果ですが「異状はなかった」とのことでした。

当方が所有するDS418Jとは、どうも中身が違うようです？。(何が違うのかはよくわかりません・・・。)


よろしくお願いいたします。

書込番号：23047234

[たく0220]

＞今日は寒い。さん

Synology以外でも同様ですが、OSの名称がDSMと同じでもモデルごとに内容や設定は異なりますので、
確認結果からだけでは、推測するのは難しいですね。

ですのでDS218+についても、mount時のオプションで"user_xattr"ついているのかと
Sambaの設定で"store dos attributes = Yes"、つまり拡張属性が有効になっているのかが気になります。
と同じ疑問を感じます。
仮にですがDS218+でそう設定されていたとすれば、「異状はなかった」というのは当然の結果かなっと思います。

NetgearのReadyNASに関してはSSHあるのですから、mount時のオプションとか同様に確認は出来ますよね。
私の知らない方法で作成日時を変更する手段があるのかもしれませんが、
DS418Jに関しては元々出来ない設定でないかなと思います。

あとExifとか対応してるカメラで撮影されたのであれば
ファイルのプロパティで詳細タブで撮影日時とか残ってませんか？

Robocopy以外でも例えばPowershellで

cd \\192.168.1.2\Test\Test01
Get-ItemProperty 1.dat | format-list

とすれば、NAS上のファイルでも作成日時をCreationTimeとして確認できます。

Set-ItemProperty 1.dat -Name CreationTime -Value "2019/11/01 1:08"

とすれば、作成日時を変更する事が出来ます。
Robocopyが原因かの切り分けぐらいにはなるかな？

ただ、拡張属性が無効のSambaサーバーに対して実行してもエラーとか返してくれないので実行後の確認は必要と感じます
Robocopyでも同様にエラーを返さないですね…

書込番号：23047614

[今日は寒い。]

＞みなさま

たくさんのご返信ありがとうございます。

Synologyより回答があり、今回の不具合を修正してもらえることになりました。多くの修正が必要だそうで、時間がかかるよです。
いつ頃になるかは不明ですので、DS418Jを継続使用するかゴミにするかは悩むところです。

みなさまのご協力、大変ありがとうございました。
感謝いたします。

書込番号：23049178

[たく0220]

＞今日は寒い。さん

不具合と認めてくれたんですね。
よかったですね！ ^^

原因が知りたいところですが、詳細は教えてくれないのでしょうね、きっと…

書込番号：23049216

[tanetty]

＞今日は寒い。さん

＞Synologyより回答があり、今回の不具合を修正してもらえることになりました。

ぬぉおおおおおおおおおおお！！！
スゴイ！　大勝利！！　すばらしい！！
他のDS481jユーザも、ニッコリですし！！

今日は寒い。さんの努力の賜物かと。
本当にお疲れさまでした　m(_ _)m

書込番号：23049464

[tanetty]

＞今日は寒い。さん

現在の熱狂(?)・安堵に水を差すようでたいへん恐縮ですが、油断大敵です。

「メーカーあるある」として、
次のように状況が短期間で激変した経験があります。
(Synology社ではなく、QNAP社ですが)

私「こういう症状です。不具合では？ 直してください」
　↓　（画面コピーやログのやりとりなどで３週間）
QNAP「不具合です(confirmed as a bug)。直します」
　↓　（２週間後）
QNAP「仕様です(working as designed)。ごめんね」

ここ(↓)の＜これまでのまとめ＞ご参照
https://bbs.kakaku.com/bbs/K0000925629/SortID=22261119/#22371569

「やっぱ、なおすのやーめた」と
Synology社が急に言い出すことも想定して
あらかじめ理論武装などなさっておくのもアリかと。

書込番号：23049553

[今日は寒い。]

＞たく0220さん

返信ありがとうございます。

＞原因が知りたいところですが、詳細は教えてくれないのでしょうね、きっと…

残念ながら、詳細は教えてもらっておりません。


＞tanettyさん

返信ありがとうございます。

＞「やっぱ、なおすのやーめた」と
＞Synology社が急に言い出すことも想定して
＞あらかじめ理論武装などなさっておくのもアリかと

QNAPの不具合対応、拝見いたしました。お疲れ様でございます。

今回の不具合については、当方だけの問題で、Synology社からの公式発表はありませんので、「やっぱ、なおすのやーめた。」というかもしれないですね。

次期製品DS420Jというのも、どこかで見たような気もしますし、今回の不具合は直さず、次の製品に移行してしまう。という場合もありそうな気もします。移行と同時にサポート終了かもしれません。

ですので、今回の不具合について、実際に直してもらえるかどうか、気長に待つことにします。直してもらえたかどうかを、ご報告できればと思います。

とりあえず、DS418Jの中にWindows標準の仮想ファイルシステムを作成して、そこ中にデータを保存しておいて、不具合が直ったら元に戻そうかと考えています。

もし、直してもらえなかったとしたら、自分で直すことはできたりしますでしょうか。

よろしくお願いいたします。

書込番号：23052501

[Excel]

>もし、直してもらえなかったとしたら、自分で直すことはできたりしますでしょうか。

これはっすねぇ・・・おそらくムリっす。
まっ、ワタクシの知識レベルではってことっすけどね。(;^_^A

あと、やったとしてもっすね、「今後のアップデートは、ゼッタイにしない！」って覚悟がいるっすねー。
DSMの機能向上とかがあったとしても、指をくわえているってゆーことになるっす。

まぁ、そのたんびに手を入れるってことならばいーんすけどね。('ω')

書込番号：23052558

[galaxy1]

>今回の不具合を修正してもらえることになりました。多くの修正が必要だそうで

何を修正するっていう話でした？

しかし、間接的な証拠から、製品に「多くの修正」箇所があるというところまで相手方に認めさせたのですから
大きな進展だと思います。瑕疵の立証責任はこちらにあるので、知らぬ存ぜぬで押し通されるときついのはこちらなので

＞「やっぱ、なおすのやーめた。」
とならないためにも、修正点がどこにあるのか抑えれればいいんですけどね

書込番号：23053019

[galaxy1]

分かりにくかったかもしれない

ようは、結局はお金の問題なのです。日本でこの種の請求をするには、瑕疵の存在は請求側が証明しないとなりません。つまり会社としては自分たちに不利な請求をさせたくないようコアの部分は伏せる方向に動くはずです。

一方、こういうソフトウェアの話になりますと技術屋さんが担当されていたりします。技術屋さんは、自身の技術屋としてのプライドがありますので単純に、原因追及に熱心になられていたりします。

今スレ主様が、メーカの何方に問い合わせされているかにもよりますがもし技術屋さんとお話しできているのなら、うまく技術屋さんの心を擽って、それとなくメーカが握っている原因を探るというのがよいかと思います。

書込番号：23053167

[たく0220]

＞今日は寒い。さん

＞もし、直してもらえなかったとしたら、自分で直すことはできたりしますでしょうか。

私はSynologyのNASを持ってませんので安易な事はいえませんし、大変だと思いますよ。
現時点でも情報が不足しているで、出来るとも出来ないとも言えないし、
何かあっても自力で解決しないといけないのでお勧めはしない。
複数のLinuxディストリビューションや組込み系のLinuxのクセを知ってれば、可能かもしれないかな。

自己責任の改造になるので、そこにどれだけのメリット・デメリットがあるのかも考えてほしいです。


書き忘れたけどDS218+とかのPlusシリーズはフォーマットにBtrfsというファイルシステムが使えるのでその辺の違いが大きいかと思う。
Btrfsはmountオプションに"user_xattr"と同様のがデフォでついてると思うので、あとはSambaがどの様に設定されてるかぐらい。
Plusシリーズだったら大丈夫かは、実機で確認するか代理店とかに確認するのがよいかと。

今回の件はJシリーズ全般同じかもしれないし、直ったからといって失った作成日時が戻ってくるようには感じられない。
自分ならDS418Jを1台残しておいて、もう1台は買替えを検討する。
(代理店とかで言質とっといて、Amazonとか返品しやすいとこで購入し、NGだったら返品する)

Synologyのアプリに依存した運用をしているなら、Plusシリーズが大丈夫だったらPlusシリーズに買替えを検討するか
QNAP、ReadyNAS等の他機種への移行も検討すると良いかと思う。

以前書いたように撮影日時がファイルから取得できるなら、そちらで確認する運用に変えるという事で妥協するという事もありかと思う。

書込番号：23053207

[今日は寒い。]

＞Excelさん
＞たく0220さん

やはり自分で直すのは、むつかしいようですので、手を出さないことにします。ありがとうございます。


＞みなさま

今回の不具合は、DSMの次期バージョン(7.0)での対応となるようです。(来年以降？、まだまだ先？)

PlusシリーズなどのBtrfsというファイルシステムでしたら、今回の不具合が発生しないようですので、乗り換えもアリかもしれないです。が、予算の問題が大きいので、乗り換えるにしても、まだまだ先になりそうです。

当面の運用をどうするかを考えながら、しばらくSynologyの様子をみて、直してくれそうにないなら、乗り換えようかと考えています。


今回の問題に関しまして、みなさまのご協力に感謝いたします。

大変ありがとうございました。

書込番号：23058128