pdumpfs-rsyncでバックアップ

だいぶ前(id:ke-k:20060118)に、バックアップと更新履歴を取れるスクリプトとして、pdumpfs(http://namazu.org/~satoru/pdumpfs/)をあげましたが、実際にはバックアップを別のマシンで取るようにpdumpfs-rsync(http://tach.arege.net/software/pdumpfs-rsync/)を使っています。で、これについてちょっと気になることが。pdumpfs-rsyncの詳しい仕様については、本家を参照していただくとして、このスクリプトって

といった手順でバックアップを取ってますが、必ずlatestと日付ごとのディレクトリに（ハードリンクでない）同じデータが入ってしまうので、最低でもバックアップ対象のデータの２倍容量使って非効率な気がするんですが、どうなんでしょう？
rsyncでlatestにコピーしたあとに、latestから日付ごとのディレクトリに全部ハードリンクしてしまえば、ディスクの使用量もファイルの比較する手間もなくなって幸せになれそうなんですが。ハードリンクだと、rsyncでlatestを更新したときに、日付ごとの方のファイルも書き換わってしまうとか？
まあ、考えてても結論が出そうにないので、スクリプトの後ろの方の

pdumpfs.update_snapshot(src, latest, today)

を

pdumpfs.update_snapshot(src, src, today)

に変えてみました。うまくいっているかどうかはしばらくすればわかることでしょうf(^^;。

File.statとFile.chownのuid

Ruby

pdumpfsを使ってバックアップを取っていると、

in `chown': bignum too big to convert into `long' (RangeError)

とのエラーが。なぜ？？と思いエラーが出たファイルを見てみると、ownerのuid,gidが4294967294になってます。なんだこれ？と思いつつ16進に直してみると、0xFFFFFFFE、32ビット符号ありで-2ってことですね。検索してみると、nobodyのuidにこいつが割り当てられることもあるみたいです。

エラーの原因ですが、chownは、符号付き32ビットの範囲しか引数を取れないようです。で、statで得られるuidは符号なし32ビットみたいです。てなわけで、0xFFFFFFFEは符号なしで4294967294と解釈されるが符号付き32ビットでは表せないためRangeErrorの例外が出てたようです。ここで、chownに-2を与えてやればうまくいくみたいなので、

  stat = File.stat(src_filename)
  uid, gid = [stat.uid, stat.gid].pack("I2").unpack("i2")
  File.chown(uid, gid, dst_filename)

のようにしてごまかしましたが、これってRubyの仕様なんですかねぇ。
それ以前に見覚えないuidが出てくるようないい加減な管理をするなって言われたらそれまでなんですがf(^^: