FAT16でフォーマットされているのでファイル名が8.3ルールに縛られている

[acidlemon]

こんにちは! こちらのツイートの件です。
https://twitter.com/acidlemon/status/1037653291453173760

imgフォルダに usalemon_hd.png を置いた状態で、そのファイルを削除して usalemon_builderscon.png をコピーしてみたのですが、再起動したところファイルが書き換わらず再マウントするとusalemon_hd.pngファイルが復活していました。

Macで確認したところ、FAT16として認識されていたため、これはまさか8.3ルール…と思い usaicon.png というファイル名で配置しなおしたところ無事画像が書き換わりました。

Macのディスクユーティリティでパーティションをアンマウントするとddコマンドでディスクイメージを吸い出せるようになるので、ディスクの先頭(MBR部分)を確認したところ、MBRはなくてパーティション切らずに直接FATのBoot Record(Jump Code + NOPの3バイトで始まるやつ)が書かれていることは確認しまして、FATのタイプを調べたところたしかにFAT16となっておりました。下記のodの出力の36hのところからです。

$ sudo umount /Volumes/NAFUDA

$ sudo dd if=/dev/disk2 bs=512 of=disk2.block count=1
1+0 records in
1+0 records out
512 bytes transferred in 0.000533 secs (960843 bytes/sec)

# ASCIIでダンプしてFAT16かFAT32か確認
$ od -Ax -c disk2.block
0000000  353   < 220   m   k   f   s   .   f   a   t  \0 002 004 004  \0
0000010  002  \0 002  \0  \0 370   |  \0      \0   @  \0  \0  \0  \0  \0
0000020    H 350 001  \0 200  \0   ) 006 340 340   )   N   A   F   U   D
0000030    A                       F   A   T   1   6             016 037
0000040  276   [   | 254   " 300   t  \v   V 264 016 273  \a  \0 315 020
0000050    ^ 353 360   2 344 315 026 315 031 353 376   T   h   i   s
0000060    i   s       n   o   t       a       b   o   o   t   a   b   l
0000070    e       d   i   s   k   .           P   l   e   a   s   e
0000080    i   n   s   e   r   t       a       b   o   o   t   a   b   l
0000090    e       f   l   o   p   p   y       a   n   d  \r  \n   p   r
00000a0    e   s   s       a   n   y       k   e   y       t   o       t
00000b0    r   y       a   g   a   i   n       .   .   .      \r  \n  \0
00000c0   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
00001f0   \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0   U 252
0000200

# hexダンプはこちらです
$ od -Ax -t x1 disk2.block
0000000    eb  3c  90  6d  6b  66  73  2e  66  61  74  00  02  04  04  00
0000010    02  00  02  00  00  f8  7c  00  20  00  40  00  00  00  00  00
0000020    48  e8  01  00  80  00  29  06  e0  e0  29  4e  41  46  55  44
0000030    41  20  20  20  20  20  46  41  54  31  36  20  20  20  0e  1f
0000040    be  5b  7c  ac  22  c0  74  0b  56  b4  0e  bb  07  00  cd  10
0000050    5e  eb  f0  32  e4  cd  16  cd  19  eb  fe  54  68  69  73  20
0000060    69  73  20  6e  6f  74  20  61  20  62  6f  6f  74  61  62  6c
0000070    65  20  64  69  73  6b  2e  20  20  50  6c  65  61  73  65  20
0000080    69  6e  73  65  72  74  20  61  20  62  6f  6f  74  61  62  6c
0000090    65  20  66  6c  6f  70  70  79  20  61  6e  64  0d  0a  70  72
00000a0    65  73  73  20  61  6e  79  20  6b  65  79  20  74  6f  20  74
00000b0    72  79  20  61  67  61  69  6e  20  2e  2e  2e  20  0d  0a  00
00000c0    00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00
*
00001f0    00  00  00  00  00  00  00  00  00  00  00  00  00  00  55  aa
0000200

[uzulla]

ご指摘ありがとうございます！

Linux上でFAT32でフォーマットして居るつもりでしたので、これは想定とはことなりますね。

mkfs.vfatで作成しているのですが、多分なにかOptionがたりないのだとおもいます、追って手法を探してみます！

[uzulla]

ただ、ファイルが「復活する（あるいは消える）」というのについては、書き込みの遅延の関係かなにかで発生する事を私のほうでは確認しており、書き込んだ後、２０秒くらいまってからとりはずすとうまくいったりしました。今回の件とは異なるかもしれませんが、ファイルが消えて戻る、という事であればそれも関係するかもしれません。

（なお、上記についてはwrite back cacheの調整が甘いのではないかとかんがえており、最新のファームではすこし調整をいれてみています（対処療法ですが）。PC側のEject時にsyncが走る処理をいれられるとよいのですが、やり方がわからず、まだ探しています。）

まだ再現テストをしておりませんが、そのあたりをふくめて確認してみたいと思います 🙇