BugTrack/701/過去のコメント

BugTrack/701

過去のコメント†

～9/26までのコメント†

• 唐突ですね (^^; メッセージが親切な分、lngへの分離が大変そうです… -- にぶんのに 2004-09-26 (日) 08:43:26
• はい、tarfile.inc.php v1.0 の発表と teananさんとのやりとりを受け、唐突に決めました (^^; このタイミングで受け取って、(CVSの上で、修正点を明確にしながら) PukiWiki本体に組み込むための作業やバランス調整を行うと、さらに早く進化するだろうと思ったのでした。 -- henoheno 2004-09-26 (日) 13:02:54
• 今はlng分離の前に、さらなる機能の検証と修練や、記録媒体に応じたダンプ動作の自動化(例えば、処理時間と転送量を考えると wiki/ ディレクトリはテキストファイルしか入っていないので絶対に圧縮すべきだが、backup/ ディレクトリは圧縮されているファイルしか入っていないので圧縮すべきでない。もし記録媒体がMySQLならやるべき事はテーブル名の特定とmysqldump + gzip。もし複数の記録媒体で実現されたものであるならばまとめて保存。等々)ができる様な内部構成の変更とPukiWiki本体の修正、tarライブラリの完全分離 (lib/ へ)、アップロードの部分の安全性の確認などをもう少し行いたいと考えています。説明やUIもそれを受けて変わるでしょう。 -- henoheno 2004-09-26 (日) 13:24:52
• あと、しばらくしたらリストアの部分はデフォルトではoffにしなければならないと思っています。管理者には便利ですが、結構危ないので (^^; -- henoheno 2004-09-26 (日) 13:45:13
• なるほど。修正前提のCVS投入とするとBugTrack（とマニュアル）への追加は待った方が良いですかね？例えばPukiWikiはzlib前提にはしていない筈なのでbackupファイルが*.txtとなる可能性がある、tar.gz形式を選択すると flockでWarning*1 が出る（環境依存?）、何故かtar(GNU tar 1.12, TAR32.dll)で復元できなかった（私だけ?）、など幾つか見つかったのですが。 -- にぶんのに 2004-09-26 (日) 14:24:51
• v1.11はデグレが発生してます。TAR_DATA_CHKBLANKSが定義されていないみたいです。 -- teanan 2004-09-26 (日) 19:13:24
• ありがとうございます。専用のBugTrackを作りましょうか 作りました :) -- henoheno 2004-09-26 (日) 19:37:33
• teananさん、ありがとうございます。デグレードの場所としては r1.4 でした。使われていない変数などを整理する途中でこれを削除してしまった様です (^^; -- henoheno 2004-09-26 (日) 20:33:55
  • cvs:plugin/dump.inc.php (v1.4:1.12)
• にぶんのにさん、マニュアルは急ぐ必要はありません。今後はどのリビジョンでお試しになったかをお教えください(恐らく上記defineが抜けているバージョンリビジョンではないかと思います (^^; )。「backupファイルが*.txtとなる可能性がある」というのはどうやってそうなるのでしょうか？ -- henoheno 2004-09-26 (日) 20:37:17
• teananさん、TARLIB_HDR_TYPE_OFFSET がコメントアウトされている理由を知りたいのですが、どのへんの資料を当たると良いでしょうか？ -- henoheno 2004-09-26 (日) 21:00:29
• typeflagは通常のファイルの場合'0'または'\0'が許容範囲なのですが、'=0'で判定できなかったため、とりあえずコメントアウトしていました。 -- teanan 2004-09-26 (日) 21:03:54
• tarのフォーマットについては、http://www.redout.net/data/tar.html で大体はわかります。他は見当たらないので、Tarのソースと他のtar.gzデータをみながら、推測して作りました (^^; -- teanan 2004-09-26 (日) 21:05:33
• む、そういえばE_ALLで試していな・・・・ *2 -- henoheno 2004-09-26 (日) 21:05:57
• ・・・flockは gzopen() が返すポインタには対応していない様なので、とりあえずflock()を取り除きました。 -- henoheno 2004-09-26 (日) 21:33:01
• いいかげんな作りで申し訳ないす :( -- teanan 2004-09-26 (日) 22:25:31
• いえいえ :) -- henoheno 2004-09-26 (日) 23:41:35

～10/07までのコメント†

• Rev1.23 でtarが展開できました。素敵～ :D -- にぶんのに 2004-09-27 (月) 02:36:16
  • で、懸案事項などを追加です。
  • buckupの*txt云々は単にlib/backup.phpにそれらしき(=zlibがdisableだと圧縮しない)コードが書いてあるだけで動作確認を取ったわけではありません。PHP 4.3.0 以降zlibがビルトインされたようですが、official:PukiWiki/インストールを見ると現状はPHP4.1.0以降なら多分オッケー、と言っているので、一応想定してあげる必要もあるのかな～と。
    • 了解です。dumpプラグインが何か影響を与えるのかと思ってしまっていました。 -- henoheno 2004-09-29 (水) 20:55:23
  • 問題提起なのですが、ページ名の変換における、危ない文字はどのOSに対してでしょうか？
    デコードは凄～く嬉しい機能なのですが、危ない文字*3はOSによって変わってくるので、マジメに考え出すと対応方法が悩ましい所だと思います。
    現状はMacOS対応のロジック？でしょうか。もしWindowsなら「\/:*?"<>|」が危ない文字です。あと予約されたDOSデバイス名*4というのもありますが、関係あるかな？関係なしでした。 Unixでも類似の制約があるはずですが、私は詳細を知らないです。
    • 現状はそこまで厳密に検討が入っていないだけなので、情報があれば適用できます -- henoheno 2004-09-29 (水) 20:55:23
  • 機能的な問題があるわけではなく、素朴な疑問なのですが、plugin_dump_disp_form()でpluginでなくcmdでdumpを呼び出しているのは何か理由があるのでしょうか。何か使い分けの基準があるとか？
    • 理由は何もないと思います。(現状はcmdもプラグインの形式で記述してあるため、呼びだし手順は変わらないはず)ただ、システム管理用の標準の機能という意味ではcmdのままでいいかもしれませんね -- henoheno 2004-09-29 (水) 20:55:23

• わたしも、試してみました。いいですね (^^) ということで、わたしもコメント -- みこ 2004-09-27 (月) 23:41:55
  • デコードは問題が多そうなのでいらないから、その代わりといっては何ですけど一覧リストのテキストがほしいです。（よくあるエディタのF10などで開ければ尚 Good (^-^ ）

    例：xxx.tar.gz[/ls-lR.txt]
    ./wiki/:
    ./wiki/50756B6957696B69.txt(1): PukiWiki
    ./wiki/53616E64426F78.txt(1): SandBox

  • （↑とってもエディタ使いな発想ですけどね (..;）
  • というわけで、こんなのどうでしょ? teanan_自作プラグイン/pagefile.inc.php
    dumpとは関係ないですね、すみません XD -- teanan 2004-09-28 (火) 00:51:01
    • うーん(^^; dumpのパッケージ(.tarもしくは.tar.gz)の中にほしい＝展開したときにエディタで探しやすくの意味なのでちょっと違うかな (^^; -- みこ 2004-09-28 (火) 01:04:03
    • なるほど、失礼しました XD -- teanan 2004-09-28 (火) 01:12:55

• ついでに、ここまで行ったならばいよいよリリースファイルにも wiki ファイルも別tarでもいいかも・・・（そうすれば、プログラム側のほうはtarを展開するだけでアップグレードが可能に？ちょっと無理かな(^^; ） -- みこ 2004-09-29 (水) 00:37:46
  • ご想像の通り、それはリスクがありますね (^^; 「PukiWiki本体」と、「データ」でアクセス権限や所有者が異なるこそ、普段はリモートからプログラムが書き換えられる心配が低いわけですので・・・ (^^; --henoheno

• 今気がつきました (T-T これは trackback/referer はバックアップ/リストアできないのでしょうか？ -- みこ 2004-09-29 (水) 11:55:10
  • 今は入っていませんが､拡張するのは簡単なはず :) -- teanan 2004-09-29 (水) 13:27:24
  • ちょっと中を確認しました。記録媒体ごとの情報がdump側とrestore側に分散しているので、これを一つにまとめた後ですね＞他のディレクトリの追加 -- henoheno 2004-09-30 (木) 00:02:26

• みこさんの提案されているファイル一覧ですが、それを作るためには一度全てのファイルをサーチしなくてはならず、そうして一覧を作成してから、実際にアーカイブが作成し終わるまでの間に、一覧の中のファイルの実体が削除されたり、あるいは知らないファイルが追加される可能性があるわけですから、負荷(処理時間)的にも実務的にも問題になりそうです。素直に tar ztvf しませんか? ・・・Unixコマンドは一般人に素直じゃないですかそうですか (^^; -- henoheno 2004-10-08 (金) 22:21:35
  • 呼ばれたみたいなので・・・作成しおわるまでのタイムラグを気にするなら素直にコンテンツをDB化する方向にうごきますし、それは現行のdumpプラグインも同じだと思っています。また、おっしゃるとおりUnixコマンドは一般人には素直ではないです。（わたしは使えますが・・・ (^^;） -- みこ 2004-10-08 (金) 23:04:12
  • えーと気にしているのは２点で、一つは処理時間が増加するという点。もう一つは一覧が現実にそぐわなくなる可能性が存在する(マーフィーの法則)という点です。タイムラグではありません (^^; いずれにせよニーズは低いという風に(気楽に)解釈しました -- henoheno 2004-10-09 (土) 00:39:22

• :) 。。o (アーカイブを作りながら「実際に追加したファイルの一覧」を用意して、それをアーカイブの先頭に追加できるのならまた違うのだけれど・・・) -- henoheno 2004-10-08 (金) 22:26:24
  • アーカイブの最後でも良いのでは・・・? -- teanan 2004-10-09 (土) 02:25:35

• BugTrack
• 開発版
  • リポジトリ
  • 開発日記
• :CategoryDev
  • PukiWiki2
  • PukiWiki/1.5
  • PukiWiki/1.4
  • PukiWiki/1.3
  • メーリングリスト
  • 開発談義
  • 雑談
• 開発者向け情報
  • Books
  • プラグイン

最新の16件