Feature #13731
closedinode for Windows on ReFS
Description
#11216 でWindowsでのinodeの代用としてBY_HANDLE_FILE_INFORMATION構造体の
メンバ、nFileIndexHigh/Lowを使っていますが、ReFS ではこの値ではユニークに
なりません。ReFSでは64ビットではなくて、128ビットでユニークな番号になります。
In https://msdn.microsoft.com/en-us/library/windows/desktop/aa363788(v=vs.85).aspx
The ReFS file system, introduced with Windows Server 2012, includes
128-bit file identifiers. To retrieve the 128-bit file identifier use the
GetFileInformationByHandleEx function with FileIdInfo to retrieve the
FILE_ID_INFO structure. The 64-bit identifier in this structure is not
guaranteed to be unique on ReFS.
128ビットの数字を入れるには現行の struct stati64 では足りません。しかし、 #13726
のパッチが受け入れられたなら stat 構造体の定義が変わるので、ついでに st_ino を
128ビットにしたら(もしくは st_ino を 64ビットにして、64ビットのメンバをもうひと
つ追加したら)どうでしょうか?
ruby 2.5 になるタイミングならABI非互換の変更も入れられるでしょう。
Updated by naruse (Yui NARUSE) over 7 years ago
- Tracker changed from Bug to Feature
- Status changed from Open to Assigned
- Assignee set to usa (Usaku NAKAMURA)
- ruby -v deleted (
trunk) - Backport deleted (
2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN)
Updated by usa (Usaku NAKAMURA) over 7 years ago
- Related to Feature #13726: PATCH: Windows builds - fractional second file times added
Updated by usa (Usaku NAKAMURA) over 7 years ago
- Related to Misc #13702: TZ checking in rb_w32_fstati64() added
Updated by usa (Usaku NAKAMURA) about 7 years ago
- Status changed from Assigned to Closed
Applied in changeset trunk|r61005.
support File.identical?
on ReFS
-
file.c (rb_file_idenitical_p): move Windows dependent code to win32/win32.c.
-
win32/win32.c (rb_w32_file_identical_p): support ReFS.
see [Feature #13731] [ruby-dev:50166]
Updated by usa (Usaku NAKAMURA) about 7 years ago
- Status changed from Closed to Assigned
stat構造体の変更は大掛かりなことになる上に、[Feature #13726] にはちょっと問題が発生しているので、とりあえず File.identical?
のみ対応しました。
stat構造体の方は 2.5 には入らないかもしれません。
Updated by kubo (Takehiro Kubo) about 7 years ago
2.5 に入らないかもしれないとのこと、了解です。
ついでですが、ReFSボリュームを作ってファイルを2つ作成し、FILE_ID_INFO の128ビットの値と nFileIndexHigh/Low の64ビットの値を取得してみました。
FILE_ID_INFOの値をリトルエンディアン128ビット整数として表記すると、以下の値が取れました。(32ビット毎にアンダースコアを付与)
- 0x00000000_00000001_00000000_00000600
- 0x00000000_00000002_00000000_00000600
一方、同じファイルの nFileIndexHigh/Low の値はそれぞれ以下のようになっていました。
- 0x30000000_00001600
- 0x30000000_00002600
サンプル数が少ないので完全に当てずっぽうですが、128ビットの値をビットシフトして、xor した値を64ビットの値として使い、64ビットにしたときの衝突が少ないように工夫しているのかもしれません。
Updated by usa (Usaku NAKAMURA) about 7 years ago
- Status changed from Assigned to Closed
Applied in changeset trunk|r61096.
support 128bit ino on Windows (if available)
-
win32/win32.c, include/ruby/win32.h (stati128, rb_{,u,l,ul}stati128): rename
from stati64ns, change the type of st_ino to 64bit and added st_inohigh. -
dir.c, file.c (stat, lstat): follow above changes.
-
file.c (rb_stat_ino): support 128bit ino.
-
win32/win32.c (rb_{,u,l,ul}stati128): ditto.
[Feature #13731]
Updated by usa (Usaku NAKAMURA) about 7 years ago
入らないかもと言いましたが、なんとか間に合わせてみました。
しかしReFSでの確認は環境がなくてできてないので、問題があったら教えてください。
Updated by kubo (Takehiro Kubo) about 7 years ago
対応ありがとうございます。ReFSでの動作テストは明日行います。
stati128_handle() の以下の部分
st->st_ino = *((unsigned __int64 *)&fii);
st->st_inohigh = *((__int64 *)&fii + 1);
&ffi
は &ffi.FileId
の間違いでしょうか?
Updated by usa (Usaku NAKAMURA) about 7 years ago
kubo (Takehiro Kubo) wrote:
stati128_handle() の以下の部分
st->st_ino = *((unsigned __int64 *)&fii); st->st_inohigh = *((__int64 *)&fii + 1);
&ffi
は&ffi.FileId
の間違いでしょうか?
おっしゃる通りです。お恥ずかしい。
r61121で修正しました。
Updated by MSP-Greg (Greg L) about 7 years ago
Usaka (and Kubo),
Thank you, with 61121 ruby-loco MinGW build is passing. I'll see what happens with a local Win7 build later on.
You're embarrassed? Don't be. How about me, as all I can do re c source issues is say 'something broke'...
Thanks again, Greg
Updated by kubo (Takehiro Kubo) about 7 years ago
ReFS と NTFS 上での File.stat(filename).ino
の値と、GetFileInformationByHandleEx()を使って得た FILE_ID_128 の値が一致することを確認しました。コンパイル時の以下の warning 以外は問題なしです。
compiling win32/win32.c
win32/win32.c: In function 'get_ino':
win32/win32.c:5445:11: warning: unused variable 'err' [-Wunused-variable]
DWORD err;
^~~
対応ありがとうございます。
Updated by usa (Usaku NAKAMURA) about 7 years ago
確認ありがとうございました。警告も消しておきました。