パスワードを忘れた? アカウント作成

アカウントを作成して、スラドのモデレーションと日記の輪に参加しよう。

2019年5月 記事 / 日記 / コメント / タレコミ
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
2019年5月9日の人気コメントトップ10
13904586 comment

yasuのコメント: MoneyForward (スコア 4, 興味深い) 36

みんなMoneyForwardはどう考えているのかな。 ECサイトどころか、銀行や証券会社のパスワードまで業者のサーバに保管しているんだけど。
13904600 comment

コメント: Re:信用 (スコア 3, すばらしい洞察) 36

また極論を・・・
最低限信用しないと機能しないものってあるでしょ。
それ言い出したら、Windowsだって使えないし、そもそも他人が作ったCPUやHDDさえ使えなくなるよ。

13904899 comment

shimotsukiのコメント: Re:Windowsでまともなファイルバックアップソフトウェアがほとんど存在しない理由 (スコア 3, 参考になる) 103

ファイル履歴は全角文字と半角文字を区別しないため、「File.txt」と「File.txt」を同一ファイルと誤認する。
そして、同一ファイルが同一フォルダに複数存在するとコケる。
でもそういうのがなくてもまともに動作しないですね。
パスの長さとかダメ文字とかなんだろうとは思いますが。
ファイルパスの余計な正規化処理が入っていて、それが国際化非対応なんでしょう。
何度も公式フォーラムで出ている話題ですが、全く改善される気配がありません。
公式フォーラムからのフィードバックしてないんでしょうね。

13904656 comment

コメント: Re:昔のMacOSのようなファイル名の制限 (スコア 3, 参考になる) 103

by Anonymous Coward (#3611689) ネタ元: Windowsにおけるファイルコピーに関する驚くほど複雑な注意点

最初の項目「(1)♪」で述べられているのは「パス文字列」なのだから、
ファイル名が短かろうと、ディレクトリ階層の奥深くにあったりしたら、
トータルのパス文字列数があっさり260を超えてしまうこともありうるのだよ。

それに自分でつけなくとも、
・ネットからファイルをダウンロードしようとしたら、それにとんでもなく長い名前が付けられていた。
・アーカイブされたファイルを展開しようとしたら、それに(以下略。
・アーカイブファイルに深いファイル構造が仕込まれていて、展開場所のパスに追加されて260文字の制限を超えてしまう。
なんてことも起きうるんだ。

13904628 comment

コメント: クロネコメンバーズの情報が漏れると (スコア 3, 参考になる) 36

皆さんのコメントを読んでると、単に追跡情報が漏れるだけみたいに思っている方が多いようですが、ヤマトが問題にしているのは「クロネコメンバーズ」のIDとパスワードの漏洩。

荷物の追跡だけなら問い合わせ番号だけでできるのですが、クロネコメンバーズでログインすると荷物の配送先の変更までできるようになります。結果として、荷物の横取り、身元を隠しての違法入手品の受け取りが自由自在にできるようになります。

13904702 comment

taka2のコメント: Re:みんなやってくれて使いやすいラッパーライブラリ (スコア 3, 参考になる) 103

ちょっと前に、HDDが死にかけたので慌てて吸い出せる分だけrobocopyで吸い出したのですが
(普通のバックアップ系ソフトでは途中でエラーになって落ちてダメだった。robocopy で何度かリトライさせれば読み取りにに成功してある程度救える状況)、

C:\Documents and Settings\ほげ\Local Settings\Application Data\Application Data\Application Data\…
と無限ループコピーしようとしたり、
「C:\Documents and Settings\ほげ」と「C:\Users\ほげ」とで二重にコピーしやがってコピー元よりもコピー先の方が容量くってたりとか
さんざんでした。今回の記事指摘のジャンクション関係はまったく対応してなさそうな感じ。

13904667 comment

コメント: Re:Windowsでまともなファイルバックアップソフトウェアがほとんど存在しない理由 (スコア 2, 興味深い) 103

by Anonymous Coward (#3611699) ネタ元: Windowsにおけるファイルコピーに関する驚くほど複雑な注意点

記事でも挙げられてるが昔からあるBackupExecはすげーよな、ADもSQL ServerもHyper-Vもちゃんと吸い出せてしかも速い。
結構な頻度で販売元が変わるのが怖いのと、テープ関連が一度動かなくなるとトラブルシューティングが難儀なの以外は価格相応の価値がある。

13904883 comment

コメント: ツッコミどころいろいろ (スコア 2, 参考になる) 103

by Anonymous Coward (#3611861) ネタ元: Windowsにおけるファイルコピーに関する驚くほど複雑な注意点

UNIXではコピー先に書き込みパーミッションの落とされたファイルがあるときに、勝手にパーミッションを立てて更新したりはしないと思うんだけど、Windowsでも間違って書き込まれたくないから読み取り専用属性を立てるんじゃないの? 上書きしていいかどうかは状況によるのでは?

BackupReadやBackupWriteに言及していないのは非同期I/Oをサポートしていないからか? しかし(公開APIでは)これ以外に読み書きの方法がないメタ情報もあるので、避けて通ることはできない。

WSLが第3のシンボリックリンク的な実装としてIO_REPARSE_TAG_LX_SYMLINKを導入した。

Vista以降ではCancelSynchronusIoという同期I/Oをキャンセルできる関数が追加された。

実際には、NT系ではゼロクリアされると仮定していい。別ドキュメントに根拠もある(Windowsのプロたるものドキュメントが相互矛盾している程度のことでうろたえてはならない)。ゼロクリアしたくないときはSetFileValidDataを使う。削除されたファイルの残骸かもしれないデータが読めてしまうのは重大なセキュリティ問題なので、この動作が変わることは考えづらい。SetFileValidDataもSeManageVolumePrivilegeを持つ(最初からボリューム全体を読み取れる)ユーザーにしか許可されていない。SetEndOfFileやSetFilePointerのドキュメントが保証を与えていないのは、Win9xではゼロクリアされなかったため。詳しくは白水氏(FastCopyの作者)のツイートを参照。

FSCTL_SET_ZERO_DATAはNT系では無駄に二重にゼロクリアするだけだし、Win9x系ではサポートされていないので、ゼロ初期化の目的で役に立つ場面はない。これは基本的にスパースファイルに穴を開けるために使うもの。

Vista以降ではGetFileInformationByHandleExでACLを無視したストリーム情報が取れるはずなので、これを使うべき。(18)を考慮しても、FindFirstStreamWがそもそもVista以降だしそれ以前のOSでもBackupReadがあるので非公開APIに出番はない。ていうかWin95時代から脳死状態でコピペを繰り返してるだけのSetEndOfFileやSetFilePointerのドキュメントの重箱の隅は異常に気にするくせにどうしてドキュメント化されていないAPIを平気で使うんだよ。

13904782 comment

コメント: Re:Googleやクラウドフレアは、児童ポルノブロッキングしていない (スコア 2, 参考になる) 48

by Anonymous Coward (#3611778) ネタ元: IIJ、DNS over TLSやDNS over HTTPSに対応するパブリックDNSサービスを開始

>法的な義務があるわけでもないのに。

児童ポルノ禁止法16条の3に義務ではないけど努力義務が定められています。
http://elaws.e-gov.go.jp/search/elawsSearch/elaws_search/lsg0500/detail?lawId=411AC1000000052#80

typodupeerror

物事のやり方は一つではない -- Perlな人

読み込み中...