くだらねえ質問はここに書き込め！Part 246

くだらねえ質問はここに書き込め！Part 246 at LINUX

[前50を表示]
450:login:Penguin
21/12/13 10:57:01.80 DbqN670Z.net
>>432
やってる内容理解してる？

451:login:Penguin
21/12/13 14:23:22.53 l8gWV1rk.net
/home/test1/
/home/test2/
/home/test3/
こういうディレクトリ構造で
test1/*
test2/再帰的に
test3/再帰的に
以下をディレクトリ名を指定せずに再帰的に削除したい場合(test1ディレクトリは残してそれ以下をすべて削除)
rm -rfじゃだめですよね
こういうのは可能ですか？

452:login:Penguin
21/12/13 14:57:03.31 y8LEKure.net
全部消したあとで mkdir /home/test1

453:login:Penguin
21/12/13 15:06:17.99 6MMlvZxF.net
find /home ! -name test1 -delete

454:login:Penguin
21/12/13 17:45:53.71 y8LEKure.net
>>429
＞渡された手順書には
手順書を渡してきた相手に確認しなくていいのか

455:login:Penguin
21/12/13 17:49:39.48 OZcMwnLN.net
>>429
> php-fpmとrh-php73-php-fpmは、いったいなんのちがいなんですか？？
パッケージのphp-fpmとrh-php73-php-fpmではPHPのバージョンが違うんじゃないですかね
こういうことは5chより上流に確認しましょう
 >>432
> あと、chown -R apache:apache フォルダ名
> このコマンドも必要なのか・・
PHP-FPMで権限分離していなければ必要かも知れません
Apacheの普通というか伝統的な構成では、PHPはmod_phpを使い、権限分離されていません
PHP-FPMでは権限分離できますが、PHP-FPMを使う理由がPHPのバージョンのみなら権限分離しない場合もあり得ます
 >>433の言うとおりで、見ていて不安になります

456:login:Penguin
21/12/13 18:22:18.51 sG9jUr8u.net
質問は全然おかしくないが、回答がおかしい
redhat系使ってないから知らんけど、package違うだけだろ
中見て自分で確認できないなら使うな

457:login:Penguin
21/12/14 08:49:32.92 N56dosO+.net
うん

458:login:Penguin
21/12/14 09:26:27.42 RZXvIBEU.net
centosってなんで嫌われてるの？

459:login:Penguin
21/12/14 11:53:25.88 yrz4WIl7.net
ローリングリリースでredhatの代わりにならなくなっちゃったから

460:login:Penguin
21/12/14 11:58:11.45 JmcE2eLm.net
本当に問題なのは、CentOS8のサポートを突如打ち切ったこと
仮にStreamが完璧な代替だとしても、明日突然打ち切りが発表されるかもしれない
もはや全く信用できなくなってしまった

461:login:Penguin
21/12/14 12:01:03.16 1lX62KUT.net
元々2029年までだったCentOS8のサポートを今月末で打ち切るという裏切り

462:login:Penguin
21/12/14 15:45:23.66 yrz4WIl7.net
そんなのredhat本体含めてどのディストリも同じでは？
メンテナンスされ続けるリリースがないと安定はしない

463:login:Penguin
21/12/14 18:08:37.47 JmcE2eLm.net
>>446
Redhat本体は一定のサポート期間を前提に客と契約して金貰ってんだから突然一方的に打ち切ったりしたら訴訟だよ
法的拘束力がなくても、嘘付きは信用できないという小学生でもわかる簡単な話だ

464:login:Penguin
21/12/14 18:10:27.67 yrz4WIl7.net
潰れちゃったら？

465:login:Penguin
21/12/15 10:51:47.55 gF15sSfq.net
>>442
> 嫌われてる
と思った理由は？

466:login:Penguin
21/12/15 12:01:39.72 UE+7N9Rj.net
坊やだからさ

467:login:Penguin
21/12/16 10:37:03.13 8jM5OeZ3.net
サーバが�

468:nッキングされて、すべてのディレクトリに.htaccessを作られましたこれを一括で削除するコマンドを教えていただけないでしょうか？日付もわかっているので、日付指定で削除したいです

469:451
21/12/16 11:03:52.62 8jM5OeZ3.net
自己レスです。とりあえず以下でなんとかなりました。
find ./ -mtime -30 -name "*.htaccess" | xargs rm -f

470:login:Penguin
21/12/16 12:33:43.89 jkX80qRi.net
centos7.9でtomcat入っていますが、log4jの問題はyumでupdateしておけば解決しますか？

471:login:Penguin
21/12/16 17:00:24.91 H+DRH/H+.net
>>451
ていうかそれ以上の事をされている可能性は気にならないのかと

472:login:Penguin
21/12/16 17:29:24.76 sObP12CD.net
>>451
サーバ稼働停止してもう稼働させないこと
それがあなたにとっての最善策

473:login:Penguin
21/12/16 18:01:18.02 8jM5OeZ3.net
>>454-455
それが共有レンタルサーバなんです。。。
踏み台用のスクリプトがありましたが、
公に公開してないので大丈夫だとは思います

474:login:Penguin
21/12/16 20:55:56.32 nByq8tra.net
まずは停止して全データを保管。
その後差分とログを確認し、問題を精査。
問題の程度が正確に分かってから、前回のバックアップに戻す。
安全と分かっている可能な範囲だけ差分を反映して復元。

475:login:Penguin
21/12/16 20:58:18.70 nByq8tra.net
log4j自体はきちんと調べて自分の責任で正しく対応しとけ

476:login:Penguin
21/12/16 22:08:50.31 a6z9G4Ps.net
>>451,456
侵入経路の特定は？まずそこからだろう
ファイル削除だけで解決する問題じゃない

477:login:Penguin
21/12/16 22:11:37.09 iB+zdARe.net
5chで尋ねるってことは
 >>451や >>453は法人のサーバーではなく個人のサーバーに関する
相談だよな？
質問の内容から法人のサーバーの管理をやるようなレベルって感じじゃないからな

478:login:Penguin
21/12/17 00:26:47.55 b+DtwiYX.net
で？

479:login:Penguin
21/12/17 00:29:50.33 nGI/YgXX.net
コロナと同じで感染者は隔離しないと他に被害が出る
かかったのが一般人だろうが医者だろうが

480:login:Penguin
21/12/17 08:01:48.17 cGNBMbkI.net
>>460
はい。個人でテスト用に使っていました。
公に公開はしていないのですが、
動作確認で設置していたスクリプトの脆弱性を突かれたみたいです。
一応、改ざんされているファイルの差分を取り
影響の範囲を調べましたが、
フィッシング用のファイルをアップされていました。
.htaccessはPHPを各ディレクトリで有効化する内容でした。

481:login:Penguin
21/12/17 11:07:53.38 rAIMsb6h.net
盗まれたパンツを取り返して履く

482:login:Penguin
21/12/17 15:14:59.60 nGkYbxgc.net
UnitファイルのExecStartで指定したスクリプト内に書いたechoがsystemctl statusで出力されないのはなんでなんだぜ？
journalctlでは出力されるんだけどここ参照してるんじゃないの？
centos7.9 kernel3.10.0-1160.49.1.el7.x86_64 systemd219

483:login:Penguin
21/12/17 15:49:08.73 vmmxJVXH.net
>>463
こういうのが後を絶たないから
何時までも踏み台にされるサーバは
この世から消えて無くならないんだろうな
よくあるのが動作確認するのにCGIを設置している奴
sshでログインして内部だけでしか動かないスクリプトなどで動作確認しろよなと思う

484:login:Penguin
21/12/17 17:02:39.63 9Bcsuer2.net
>>465
ExecStart行は、そこに書かれたプログラムを、
それぞれ子プロセスをおこして動作させてる
そしてstatusでは、ExecStartで起動したプロセスのうち、
その時に起動しているプロセスが出したログだけを
表示している
echoとかはすぐに終了してるので、statusでは出力されないよ

485:login:Penguin
21/12/17 17:10:42.83 nGkYbxgc.net
そゆことか、ありがとう

486:login:Penguin
21/12/17 17:31:22.31 WDpFyAGb.net
２つHDD接続してます
# btrfs filesystem show
Label: 'debian' uuid: cf82c300-5af6-45d6-a682-1e93b9105cae
Total devices 1 FS bytes used 25.51GiB
devid 1 size 295.90GiB used 39.07GiB path /dev/sda2
Label: 'debian' uuid: 3a396f2a-5ad7-47af-9bbd-343195f050f2
Total devices 1 FS bytes used 21.17GiB
devid 1 size 146.84GiB used 25.07GiB path /dev/sdb2
以下のごとくsdb2のみ　エラーが出て起動できません。直近に当該ディスクドライブが、ゴロンゴロンまともにスピンしませんでした。げんざいは綺麗にスピンしてます。
# dmesg
BTRFS errorのみ
[ 6576.245236] BTRFS error (device sdb2): parent transid verify failed on 577110016 wanted 1415 found 1373
[ 6576.252368] BTRFS info (device sdb2): no csum found for inode 217067 start 0
[ 6576.264856] BTRFS warning (device sdb2): csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1
[ 6576.281548] BTRFS error (device sdb2): parent transid verify failed on 577093632 wanted 1415 found 1373
[ 6584.082394] BTRFS error (device sdb2): parent transid verify failed on 577110016 wanted 1415 found 1373
[ 6584.082408] BTRFS info (device sdb2): no csum found for inode 217067 start 0
[ 6584.095117] BTRFS warning (device sdb2): csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1

487:login:Penguin
21/12/17 17:49:53.43 EEXs8ixD.net
良かったね。次の方どうぞ～

488:login:Penguin
21/12/17 18:00:28.63 WDpFyAGb.net
見やすくするために
[ 6584.082394] BTRFS error (device sdb2):
等の文字列をのぞいきました
parent transid verify failed on 577110016 wanted 1415 found 1373
no csum found for inode 217067 start 0
csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1
parent transid verify failed on 577093632 wanted 1415 found 1373
parent transid verify failed on 577110016 wanted 1415 found 1373
no csum found for inode 217067 start 0
csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1

489:login:Penguin
21/12/17 18:03:35.77 WDpFyAGb.net
なおすでに
# btrfs rescue zero-log /dev/sdb2
を実行。
参考
URLﾘﾝｸ(github.com)
これをする前はマウントすらできませんでした。

490:login:Penguin
21/12/17 18:07:26.49 WDpFyAGb.net
>
"chunk tree"という文字列を含むメッセージが出力されている。
どのデバイスにどのデータを配置するかという情報が入っているchunk treeというメタデータが壊れている可能性があります。次のコマンドによって、ファイルシステムをスキャンしてchunk treeを復元できます。
# btrfs rescue chunk-recover /dev/sdb2
"chunk tree"という文字列を含むメッセージが出力されてませんが、実行。
# btrfs rescue chunk-recover /dev/sdb2
ERROR: the device is busy

491:login:Penguin
21/12/17 18:17:43.77 WDpFyAGb.net
大段
■mountできなくなった
<<（我）もうすでにマウントはできてるのですが...
中の
□mountに必要なメタデータの復元
これ以降の操作はmountできなくなったBtrfsファイルシステムを構成するストレージの内容を変更します
中の
-----------------------------------------
それ以外のメッセージが出ている、あるいはとくにメッセージが残っていない
大きく分けて次の2つの可能性が考えられます。
スーパーブロック(後述)が壊れている
root tree(後述)が壊れている
-----------------------------------------
第一にスーパーブロックが壊れている場合です。スーパーブロックとは、mountしようとしたストレージがBtrfsに属していることを示すと共に、各種管理情報を保持しているメタデータ�

492:ﾅす。このデータにはバックアップされていますので、スーパーブロックが壊れている場合は次のコマンドによって復元できます。 # btrfs rescue super-recover /dev/sdb2 ERROR: the device is busy

493:login:Penguin
21/12/17 18:23:19.92 WDpFyAGb.net
第二にroot treeが壊れている場合です。root treeとは、どの場所にどんなデータ/メタデータが配置されているかを管理するメタデータです。壊れたroot treeを復元するには次のようにします。
# mount -o usebackuproot /dev/sdb2 /mnt 　　　　<< 行末はマウントポイントを指定ということか？
$ lsblk
sdb 8:16 0 149.1G 0 disk
├─sdb1 8:17 0 260M 0 part
├─sdb2 8:18 0 146.9G 0 part /media/jin/debian
└─sdb3 8:19 0 2G 0 part

# mount -o usebackuproot /dev/sdb2 /media/jin/debian
# mount -o usebackuproot /dev/sdb2 /media/jin/debian
mount: /media/jin/debian: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error.
#
んんん～？

494:login:Penguin
21/12/17 18:31:24.82 WDpFyAGb.net
ファイルシステムの復元(最終手段)
# btrfs check --repair /dev/sdb2
このコマンドは矛盾のあるデータは容赦無く削除するなどして無理矢理にでもmountできるようにするためのものであり、かつ、必ずしも成功するとは限りません。このため、他に打つ手がまったく無くなったときの最後の手段として使用してください
# btrfs check --repair /dev/sdb2
enabling repair mode
WARNING:
Do not use --repair unless you are advised to do so by a developer
or an experienced user, and then only after having accepted that no
fsck can successfully repair all types of filesystem corruption. Eg.
some software or hardware bugs can fatally damage a volume.
The operation will start in 10 seconds.
Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
ERROR: /dev/sdb2 is currently mounted, use --force if you really intend to check the filesystem
#
<< マウントしてない状態でやるのか

495:login:Penguin
21/12/17 18:31:28.34 WDpFyAGb.net
# btrfs check --repair /dev/sdb2
enabling repair mode
WARNING:
Do not use --repair unless you are advised to do so by a developer
or an experienced user, and then only after having accepted that no
fsck can successfully repair all types of filesystem corruption. Eg.
some software or hardware bugs can fatally damage a volume.
The operation will start in 10 seconds.
Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
Checking filesystem on /dev/sdb2
UUID: 3a396f2a-5ad7-47af-9bbd-343195f050f2
[1/7] checking root items
parent transid verify failed on 579682304 wanted 1415 found 1372
parent transid verify failed on 579682304 wanted 1415 found 1372
parent transid verify failed on 579682304 wanted 1415 found 1372
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=578355200 item=136 parent level=1 child bytenr=579682304 child level=1
ERROR: failed to repair root items: Input/output error
#

496:login:Penguin
21/12/17 18:36:00.69 WDpFyAGb.net
警告
開発者からアドバイスがない限り、--repair は使用しないでください。
ということを理解した上で、そのうえで行ってください。
fsck はあらゆる種類のファイルシステムの破損を正常に修復することができます。例えば
いくつかのソフトウェアやハードウェアのバグは、ボリュームに致命的な損傷を与える可能性があります。
[1/7] ルートアイテムのチェック
parent transid verify failed on 579682304 wanted 1415 found 1372
parent transid verify failed on 579682304 wanted 1415 found 1372
parent transid verify failed on 579682304 wanted 1415 found 1372
トランシッドの失敗を無視する
ERROR: 子ebが破損: 親 bytenr=578355200 item=136 親レベル=1 子 bytenr=579682304 子レベル=1
ERROR: ルートアイテムの修復に失敗しました。入出力エラー
#
＜＜以上機械翻訳
# btrfs rescue super-recover /dev/sdb2
ERROR: the device is busy 　＜＜先に実行したコマンドでこの意味がわからなかったが、
<< マウントしてない状態でやるのか　ということでは？
もう一度やり直し

497:login:Penguin
21/12/17 18:52:25.42 EEXs8ixD.net
そうなんだ～ふむふむ～
次の方どうぞ～

498:login:Penguin
21/12/17 21:38:04.36 WDpFyAGb.net
"chunk tree"という文字列を含むメッセージが出力されている。
どのデバイスにどのデータを配置するかという情報が入っているchunk treeというメタデータが壊れている可能性があります。次のコマンドによって、ファイルシステムをスキャンしてchunk treeを復元できます。
# btrfs rescue chunk-recover /dev/sdb2
このコマンドはストレージプールのすべてを走査するため、非常に時間がかかる恐れがあります。
----------------
# btrfs rescue chunk-recover /dev/sdb2
Scan

499:ning: 104862273536 in dev0 すごい長い時間かかてる、、、

500:login:Penguin
21/12/17 21:57:42.58 EEXs8ixD.net
ここはお前の日記帳じゃねーんだよｗ技術力ゼロのおっさんｗ

501:login:Penguin
21/12/17 22:00:46.28 WDpFyAGb.net
# btrfs rescue chunk-recover /dev/sdb2
Scanning: DONE in dev0
We are going to rebuild the chunk tree on disk, it might destroy the old metadata on the disk, Are you sure? [y/N]: y
Chunk tree recovery aborted
#
おわた
dmesg　どうなった？
# dmesg | tail
[11570.040916] usb 6-3: Product: WN-G300UA
[11570.040920] usb 6-3: Manufacturer: I-O DATA DEVICE, INC.
[11570.040923] usb 6-3: SerialNumber: 00e04c000001
[11570.857132] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11570.884652] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11571.107981] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11571.163660] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[11572.726292] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[14120.958897] sysctl (11524): drop_caches: 3
[14143.358555] Adding 2097148k swap on /dev/sda3. Priority:-2 extents:1 across:2097148k FS
#
消えた、btrfs 関連エラー？？
ひとつだけになった？
[10621.063512] BTRFS error (device sdb2): Remounting read-write after error is not allowed

502:login:Penguin
21/12/17 22:18:17.99 WDpFyAGb.net
だめだなー。起動できない。initramfs みたいな
さっきの日本語参考ページの元ネタってぽい英語ページにしたがってやってゆこうか
URLﾘﾝｸ(ownyourbits.com)
＞Be prepared
準備して
Rule zero is of course to have backups.
もちろん、ルールゼロはバックアップをとることです。
This will allow us to sleep well at night and handle a bad drive situation with a much cooler head.
これにより、私たちは夜よく眠り、はるかに涼しい頭で悪いドライブ状況に対処することができます。
I can’t stress this enough: have at least three copies in two different locations.
これを十分に強調することはできません。2つの異なる場所に少なくとも3つのコピーがあります。
Everything will be easier and less stressful when a drive fails, which will happen.
ドライブに障害が発生した場合、すべてが簡単になり、ストレスが軽減されます。
＜＜　sdb の中にあるスナップショットはバックアップになんないのか？
また、このsda中のスナップショットでは、ファイルシステムを復元できないのか１

503:login:Penguin
21/12/17 22:19:55.07 WDpFyAGb.net
Then, rule number one is to monitor your hard drive’s health.
次に、ルール1は、ハードドライブの状態を監視することです。
This is also critical because normally you will get the warning at least 24 or 48 hours before total failure so you have a good chance of getting your data out of there before it is too late.
通常、完全な障害が発生する少なくとも24時間または48時間前に警告が表示されるため、手遅れになる前にデータを取得できる可能性が高いため、これも重要です。
Hard drives don’t completely fail from one day to the other but we need to pay attention to them.
ハードドライブは、ある日から別の日に完全に故障するわけではありません
--------------------
とりあえずスマート有効にして、値を見てみるところからはじめる

504:login:Penguin
21/12/17 22:28:05.94 WDpFyAGb.net
問題ディスク
ST3160815AS (3.AAC)
であるが、
890 個の不良セクターがありますが、使用可能です (35 °C / 95 °F)
＜＜以前と同じメッセージ
リアロケーティッドセクタカウント
カレントペンディングセクタカウント
アンコレクタブルセクタカウント　　　等の重要な値も以前といっしょ
エアフロー温度だけ　赤字で「過去に失敗した」と出ている

505:login:Penguin
21/12/17 22:47:38.76 WDpFyAGb.net
これらの参考ページはすべて
Procedure if the drive can be mounted
ドライブをマウントできるかどうかの手順
であって、俺の環境はすでにマウントできてる
だからぜんぜん別の修復方法がありそうなものだ
> 復元したい日付のディレクトリへ入り、
$ cd /media/ユーザ/debian/timeshift-btrfs/snapshots/2021-12-13_16-08-21
これじゃダメなのか？（じつはもうやった、リードオンリーと出てできない）

506:login:Penguin
21/12/17 22:56:45.86 EEXs8ixD.net
惨めな荒らしだな・・・

507:login:Penguin
21/12/17 23:31:03.92 myoXf6ap.net
ここは質問を書き込むところで日記や備忘録を書き込むところではないはずなんだが
ぐだぐだ書かずにやったこととやりたいことだけ書いて質問して
HDDの内容吸い出せなかったら壊れたとして諦めるか専門業者に頼め

508:login:Penguin
21/12/17 23:48:40.01 EEXs8ixD.net
専門業者と同じレベルのことが出来ない悲しさあるな・・・別に専用の機材が必要なわけじゃないから出来ること同じなのにｗ
見てて恥ずかしいわｗ

509:login:Penguin
21/12/18 00:14:02.88 HnVQUw9E.net
□やったこと
URLﾘﾝｸ(github.com)
このページのすべてのコマンド
一つだけ効果があった
# btrfs rescue zero-log /dev/sdb2
でマウントできるになった。
しかしsdbのシーゲートから起動できない。
□やりたいこと
＞HDDの内容吸い出し
ではなく、デビアンの正常起動
> 復元したい日付のディレクトリへ入り、
cd /media/jin/debian/timeshift-btrfs/snapshots/2021-12-13_16-08-21
して
$ sudo btrfs sub snap @ /media/jin/debian
か
$ sudo btrfs sub snap @ /media/jin/debian/@
みたいな感じでスナップショットからファイルシステムを復元できないかと？しかしやってみると
ERROR: cannot snapshot '@': Read-only file system
となりま。
□壊れたとして諦める
このディスクはあかん。しばらくオッケーに見えて１ヶ月以内に必ずダメになりますWWW
それでもなんとかしてほしい！！　とりあえずいまだけ！！

510:login:Penguin
21/12/18 00:15:10.44 HnVQUw9E.net
俺はすべてのパーツをぜったいに　あきらめないっ
-----------------------------------------
電気が入らなくなるまでっっ
-----------------------------------------

511:login:Penguin
21/12/18 00:52:04.61 poEKAKYQ.net
状況も分からずデタラメにコマンド叩いてるだけじゃ悪化するだけだわ恥ずかしいｗ

512:login:Penguin
21/12/18 01:28:08.14 JBIVhS6S.net
無駄に足掻く時間が勿体無いからストレージをクローンかイメージ化して取れるものだけ取って後は諦めるけどな

513:login:Penguin
21/12/18 08:26:10.45 kJlm2/Qf.net
> 26 login:Penguin sage 2021/11/10(水) 00:03:48.68 ID:U/pJYCBd
> debian10busterはsdb 298.1G HGST_HTS545032A7E680 にあります。大きい容量から小さい容量のHDDへコピーする方法を教えて下さい。
こいつだから
あとは本人がちゃんと

514:説明するかどうか

515:login:Penguin
21/12/18 08:46:14.29 poEKAKYQ.net
1ヶ月以上かけてこの進捗じゃもう向いてないとしか言いようがない

516:login:Penguin
21/12/18 08:56:43.16 fe9H0Vwc.net
ガガガガイ

517:login:Penguin
21/12/18 09:35:13.91 nN8WfFGQ.net
>>494
その人なのか。おそらく同一人物らしい人がそれ以前にdebianスレで
btrfs助けてと来ていたな。
だから、>>495、一か月どころじゃないと思う

518:login:Penguin
21/12/18 09:41:39.00 HnVQUw9E.net
よし、オメーラ。いまからOracle® Linux 6管理者ソリューション・ガイドをいっしょに読んでいくぞ
4.6 サブボリュームとスナップショットの作成
btrfsファイル・システムの最上位レベルは、ディレクトリやファイルを含む名前付きのBツリー構造で構成されたサブボリュームであり、
＞btrfsファイル・システムの最上位レベルは
これはわかる
＞ディレクトリやファイルを含む
これもわかる
＞名前付きのBツリー構造で構成されたサブボリュームであり、
はぁ？ww
＞サブボリュームを作成するには、サブボリュームを作成するbtrfsファイル・システム内の位置にディレクトリを変更し、次のコマンドを入力します。
サブボリュームなんか作成したことねーぞ。タイムシフトで勝手に作成されるみたいだな。
＞サブボリュームを作成するbtrfsファイル・システム内の位置にディレクトリを変更し
ここは前に指導受けてわかる。
# btrfs subvolume create subvolume_name
-----------------------------------------
はやく
$ sudo btrfs sub snap @ /　　の使い方出てこねえかな？

519:login:Penguin
21/12/18 09:43:27.81 HnVQUw9E.net
>>497
おはよーござい、ます！

520:login:Penguin
21/12/18 09:45:08.66 HnVQUw9E.net
スナップショットは、スナップショットの取得時に親のサブボリュームの内容を記録するサブボリュームの一種です。
btrfsファイル・システムのスナップショットを取得し、それに書込みを行わないと、そのスナップショットは元のファイル・システムの状態を記録し、バックアップを作成できる安定したイメージになります。
スナップショットを書込み可能にすると、それを元のファイル・システムの代替バージョンとして使用できます。
btrfsファイル・システムのコピーオンライト機能では、スナップショットを迅速に作成でき、当初はほとんどディスク領域を消費せずに済みます。
<< 以上は特に問題ねえ。ほぼわかる。感覚だけだけどw

521:login:Penguin
21/12/18 09:45:26.52 kJlm2/Qf.net
ファイルシステム自体の詳細な質問はこちらで
ファイルシステム総合スレその19
ｽﾚﾘﾝｸ(linux板)

522:login:Penguin
21/12/18 09:49:11.42 HnVQUw9E.net
URLﾘﾝｸ(docs.oracle.com)
次の表に、一般的なスナップショット操作を実行する方法を示します。
コマンド
説明
btrfs subvolume snapshot (pathname) pathname/snapshot_path
pathnameによって指定された親のサブボリュームまたはスナップショットのスナップショットsnapshot_pathを作成します。次に例を示します。
btrfs subvolume snapshot /mybtrfs /mybtrfs/snapshot1
<<ウワーッ。説明と例がわかりにくいなあ

523:login:Penguin
21/12/18 09:49:59.01 HnVQUw9E.net
>>501
> ファイルシステム自体の詳細な質問はこちらで
> ファイルシステム総合スレその19
> ｽﾚﾘﾝｸ(linux板)
クソスレ時間のむだ。くだ質で。

524:login:Penguin
21/12/18 09:52:23.42 kJlm2/Qf.net
そっちの方が専門的な識者が多いから誘導してやってるのだが

525:login:Penguin
21/12/18 09:55:43.82 HnVQUw9E.net
>btrfsサブボリュームは、ディスク・デバイスのようにマウントできます。親のサブボリュームのかわりにスナップショットをマウントすると、ファイル・システムの状態をスナップショット取得時の状態に効率的にロールバックできます。
オラクルのページはもう終わるから待っとけ

526:login:Penguin
21/12/18 09:58:41.86 HnVQUw9E.net
とりあえずライブ起動で、btrfs subvolume snapshot (pathname) pathname/snapshot_path
やって結果出して、エラーメッセ記録してググりだな。これしか突破口はねえ。俺の習得した数少ない
スキルだからな。

527:login:Penguin
21/12/18 10:00:39.29 poEKAKYQ.net
無能な荒らしとか悲惨だな・・・

528:login:Penguin
21/12/18 10:03:13.40 poEKAKYQ.net
ちなみに俺ファイルシステムのコード書いたり読んだりするよｗまじ恥ずかしいｗ

529:login:Penguin
21/12/18 10:11:46.47 kJlm2/Qf.net
おお、意外

530:なところに有識者様が便乗質問おｋすか？Btrfsじゃないんですが

531:login:Penguin
21/12/18 10:25:37.70 6Mq81OPl.net
zipinfo とか zcat で圧縮ファイルの中身のファイル一覧を見れますが、たとえば hoge.zip の中身の fuga.txt を、hoge.zip を解凍せずに閲覧する方法はありますか

532:login:Penguin
21/12/18 10:39:00.10 poEKAKYQ.net
あるよ

533:login:Penguin
21/12/18 11:07:40.71 lkysTqFs.net
こいつがっていうより、こいつにかまうヤツがクソ

534:login:Penguin
21/12/18 11:15:21.47 2w4RaGuj.net
じゃあこいつらがってことか

535:login:Penguin
21/12/18 11:23:37.75 poEKAKYQ.net
ええやん、いくらでも構ってやればｗ有用な情報は一切教えないけどｗ

536:login:Penguin
21/12/18 11:27:41.35 2w4RaGuj.net
わかってないようだ

537:login:Penguin
21/12/18 11:31:03.43 poEKAKYQ.net
もう何十年もココ使ってるけど、どうせどこかを荒らすんだろ？ここでいいやんｗ

538:login:Penguin
21/12/18 11:34:47.30 yA2xs9mM.net
埋め立てなら荒らし報告を

539:login:Penguin
21/12/18 11:45:07.01 poEKAKYQ.net
荒らし報告なんてあからさまな宣伝みたいなやつを除いて昔から機能してないよ
ただの私怨にしかならんしな

540:login:Penguin
21/12/18 11:47:17.72 2w4RaGuj.net
十分機能はしているが現在浪人持ちのみが報告可能
ただし今日のケースではおそらく規制されない

541:login:Penguin
21/12/18 11:52:28.33 poEKAKYQ.net
機能してるところなんて見たことないけどな
いっつも荒らされてるやんｗ

542:login:Penguin
21/12/18 11:56:25.72 2w4RaGuj.net
いっつもがいつの何処の事を言ってるのかでそのレスの適切さが分かれる

543:login:Penguin
21/12/18 12:06:36.73 6nc117Ed.net
>>510
unzip -p archive.zip inner.txt

544:login:Penguin
21/12/18 12:09:57.47 poEKAKYQ.net
見てれば実感としてあるだろｗ証明するまでもない。この板で調べればすぐ分かるよｗ

545:login:Penguin
21/12/18 12:10:42.35 poEKAKYQ.net
リダイレクトについて書いた方がいい

546:login:Penguin
21/12/18 12:13:15.59 2w4RaGuj.net
と言う事で見事にいろいろ浮き彫りにされたID:poEKAKYQなのであった

547:login:Penguin
21/12/18 12:21:17.00 poEKAKYQ.net
IP調べれば一発だっつーの。余計なことにスレを使うなｗ

548:login:Penguin
21/12/19 17:17:21.73 U/RU1xeH.net
皆さんただいま。作業報告の続きです
この後がどうしたらいいかわかりません。よろしくおながいします

549:login:Penguin
21/12/19 17:18:03.36 U/RU1xeH.net
# Mapfile. Created by GNU ddrescue version 1.23
# Command line: ddrescue -fdvr3 /dev/disk/by-id/ata-ST3160815AS_6RX65VV6 /media/user/debian1/ST.img ddrescue.map
# Start time: 2021-12-19 06:49:20
# Current time: 2021-12-19 07:40:52
# Finished
# current_pos current_status current_pass
0x25433D0000 + 1
# pos size status
0x00000000 0x25433D6000 +

550:login:Penguin
21/12/19 17:25:54.56 U/RU1xeH.net
□記録を調べたところ、過去にまったく同じケースで指導を受けていた。
ERROR: cannot snapshot '@': Read-only file system
となる　このケースはハードドライブの障害であり ddrescue を使う。2台のHDD を接続してdebian live usbで起動
user@debian:~$ sudo apt update
user@debian:~$ sudo apt install gddrescue
user@debian:~$ lsblk -o name,label,size,fstype,model
NAME LABEL SIZE FSTYPE MODEL
loop0 2.7G squashfs
sda 149.1G ST3160815AS
├─sda1 EFI 260M vfat
├─sda2 debian 146.8G btrfs
└─sda3 2G swap
sdb 298.1G HGST_HTS545032A7E680
├─sdb1 EFI 190M vfat
├─sdb2 debian 295.9G btrfs
└─sdb3 2G swap
sdc 28.6G SanDisk_3.2Gen1
└─sdc1 D-LIVE NF B 28.6G vfat

551:login:Penguin
21/12/19 17:27

552::59.83 ID:U/RU1xeH.net

553:login:Penguin
21/12/19 17:31:47.02 U/RU1xeH.net
user@debian:~$ sudo ddrescue -fdvr3 /dev/disk/by-id/ata-ST3160815AS_6RX65VV6 /media/user/debian1/ST.img ddrescue.map
GNU ddrescue 1.23
About to copy 160041 MBytes from '/dev/disk/by-id/ata-ST3160815AS_6RX65VV6' to '/media/user/debian1/ST.img'
Starting positions: infile = 0 B, outfile = 0 B
Copy block size: 128 sectors Initial skip size: 3200 sectors
Sector size: 512 Bytes
Press Ctrl-C to interrupt
ipos: 160041 MB, non-trimmed: 0 B, current rate: 7299 kB/s
opos: 160041 MB, non-scraped: 0 B, average rate: 51810 kB/s
non-tried: 0 B, bad-sector: 0 B, error rate: 0 B/s
rescued: 160041 MB, bad areas: 0, run time: 51m 28s
pct rescued: 100.00%, read errors: 0, remaining time: n/a
time since last successful read: n/a
Finished
user@debian:~$

554:login:Penguin
21/12/19 17:41:17.85 U/RU1xeH.net
さて、ST.img はどこにあるのか？自分ではわからないが、記録では次のコマンドを打っている。
$ sudo timeshift --list
/dev/sda2 is mounted at: /run/timeshift/backup, options: rw,relatime,space_cache,subvolid=5,subvol=/
<< BTRFSでは、/dev/sda2は/run/timeshift/backupにマウントされているのか？いままでコマンドの出力をまともに読んだことがねえから初めて気付いた。という「マウントの意味をさいきん知った」
Device : /dev/sda2
UUID : cf82c300-5af6-45d6-a682-1e93b9105cae
Path : /run/timeshift/backup
Mode : BTRFS
Status : OK
1 snapshots, 134.8 GB free
Num Name Tags Description
------------------------------------------------------------------------------
0 > 2021-12-19_17-09-08 B

$

555:login:Penguin
21/12/19 17:41:31.70 U/RU1xeH.net
さて、ST.img はどこにあるのか？自分ではわからないが、記録では次のコマンドを打っている。
$ sudo timeshift --list
/dev/sda2 is mounted at: /run/timeshift/backup, options: rw,relatime,space_cache,subvolid=5,subvol=/
<< BTRFSでは、/dev/sda2は/run/timeshift/backupにマウントされているのか？いままでコマンドの出力をまともに読んだことがねえから初めて気付いた。という「マウントの意味をさいきん知った」
Device : /dev/sda2
UUID : cf82c300-5af6-45d6-a682-1e93b9105cae
Path : /run/timeshift/backup
Mode : BTRFS
Status : OK
1 snapshots, 134.8 GB free
Num Name Tags Description
------------------------------------------------------------------------------
0 > 2021-12-19_17-09-08 B

556:login:Penguin
21/12/19 17:44:47.43 U/RU1xeH.net
$ ls /run/timeshift/backup
@ @home ST.img timeshift-btrfs
おお！あったぞRaw disk image 　サイズ160.0 GB (160041885696 バイト)
-----------------------------------------
つぎの作業を指示して下さい。マジでわかりません。予想としては書き戻す、コマンドがぜんぜん！！

557:login:Penguin
21/12/19 17:47:47.27 U/RU1xeH.net
>>514
> ええやん、いくらでも構ってやればｗ有用な情報は一切教えないけどｗ
オメーのような脳無しのもたらす情報は遮断するww おれに指導できるのは天才児だけだ。
なぜならばおれはリナックス界の風雲児だからだ。

558:login:Penguin
21/12/19 17:51:16.95 U/RU1xeH.net
複数の板で重要な論文を発表中で、そちらの作業に出かけてきます。
ひとつはアイドルの板で、あるアイドルの死について考究する。目的はスレ民の不安をとりのぞくこと。

559:login:Penguin
21/12/19 18:25:21.82 FlGVfwTG.net
よお風雲児
残念だがそのレベルのトラブルは俺には回答不可能だ
そのレベルになるまでHDDをこき使ったことが無いので
強いて言うならばいつそうなってもいいように外付けストレージやファイル鯖にバックアップを取っておくべきだったな
もっともトラブってる方は予備なんだから大して痛くなかろうよ

560:login:Penguin
21/12/19 19:11:23.98 1dJM5IFQ.net
はいはい、ID変えてご苦労さまとも見えるレスだな
出鱈目やってるだけの日記に回答不可なんてありえないｗ
本来必要な手順を省き、やってはいけない操作をやって破壊するだけの作業には誰も�

561:ｻ味などない

562:login:Penguin
21/12/19 19:15:23.31 U/RU1xeH.net
>>538
これがアホの認定厨...w

563:login:Penguin
21/12/19 19:16:08.90 ACzmpV+n.net
偏執的なところも追求するためには必要な要素なのかもしれんが
天才さんなら時間の無駄と思って諦めたりしないんかね

564:login:Penguin
21/12/19 19:20:12.05 U/RU1xeH.net
>>537
> 強いて言うならばいつそうなってもいいように外付けストレージやファイル鯖にバックアップを取っておくべきだったな
そのやり方がわからんもん。。。
> もっともトラブってる方は予備なんだから大して痛くなかろうよ
次郎さんか？オメーは知能が高いのに、なんで下らねえ２ちゃん民の評判なんか気にするんだ？
そこがオメーのいちばんアカンところなんだわ。ひとことでゆーと弱い！！www わかったな？

565:login:Penguin
21/12/19 19:23:41.72 U/RU1xeH.net
>>540
> 偏執的なところも追求するためには必要な要素なのかもしれんが
> 天才さんなら時間の無駄と思って諦めたりしないんかね
ハッキリいいます。昔からの言い伝えで「タイム　イズ　マネー」とあります。
このシーゲートは、意味がありません。まえに一ヶ月以内に壊れると言いましたが、サバを読んだ。
じつは２週間以内にかならずOSは壊れるw
だから修復技の習得のために、やってるの。

566:login:Penguin
21/12/19 20:00:58.42 FlGVfwTG.net
俺は評判を気にすると言うよりはあまり無責任な回答をつけたくないだけ
そんなに熟練者でもないんで不良HDDからのデータサルベージなんてddrescueで駄目だったらお手上げレベルよ
こんな下っ端じゃなくとも紳士的振る舞いさえ出来ればきっとスゴウデの人が助けてくれるさ

567:login:Penguin
21/12/19 20:10:09.82 FlGVfwTG.net
> だから修復技の習得のために、やってるの。
だと言うならば少なくとも俺では力不足だな
ツールまかせのサルベージしかできんもの
「おまえら詳しいんだから教えろや」ではなく一貫して「ご面倒でしょうけどどうかご教示下さい」と言う態度でこっちで聞く事をすすめる
ファイルシステム総合スレその19
ｽﾚﾘﾝｸ(linux板)

568:login:Penguin
21/12/19 22:24:24.35 1dJM5IFQ.net
そっちに行ったところで俺が潰すから大丈夫ｗ

569:login:Penguin
21/12/19 22:34:51.60 FlGVfwTG.net
それはご自由になさって下さればよいかと
Btrfsに関しては教えられることは教えたけど不良ドライブからの難儀なサルベージまではちょっと

570:login:Penguin
21/12/19 22:37:21.83 1dJM5IFQ.net
あと修復技の習得にはなってなくて、誰も必要としない破壊技を修復技と思って習得してるだけだからｗ

571:login:Penguin
21/12/19 22:41:05.67 FlGVfwTG.net
良く言えば本人は緊急時対応の修行とでも思ってるのでしょう
普通はそうなる前にバックアップ取っておいてドライブが故障する前に交換するものだけど

572:login:Penguin
21/12/20 20:46:08.59 PUJobghu.net
15年ぐらい前からftpといわゆるホームページ作成ソフトで
たくさんの人が同一アカウントで好き勝手にファイルを置いている環境があるんだけど、
端末(bash環境)でトップからどこにもリンクされていない幽霊ファイルを検出する方法とかありますか？
htaccssとかは除外するとして、cgiが吐くファイルとかもあるだろうから、
そういうのはディレクトリ名で判断して消さないようにします

573:login:Penguin
21/12/20 20:52:20.64 Oa8J25Rn.net
あるよ

574:login:Penguin
21/12/21 07:34:00.51 Rlb1gRlA.net
よくこんなスレで真っ赤にできるよな天才だわ

575:login:Penguin
21/12/21 11:31:36.92 F3C3+VFl.net
>>549
リンクとは？

576:login:Penguin
21/12/21 14:24:16.43 GgAzq/Ob.net
curl/wget でダウンロードせずに、
リソースのURL だけを取得するようなオプションは無いのか？
例えば、ボタンを押すと、Ajax でHTML を書き

577:換えて、今まで存在しなかった、URLが現れると、非常に厄介 5ch がそう最初に空のHTMLを送ってきてから、Ajaxで内容を取得する。そこには、200のURLが書いてあるが、ボタンを押せば、500のURLが現れるこのように、ユーザーのアクションによって、ドンドンHTMLが変わっていくので、その中にあるURLも変わっていくのが、厄介

578:login:Penguin
21/12/21 14:26:33.64 GQ6sbGvt.net
お得意のRuby使えよ

579:login:Penguin
21/12/21 14:28:59.33 LG40fTb8.net
javascript動かしたいならブラウザをheadlessで動かす仕組みのやつを使え

580:login:Penguin
21/12/21 15:19:56.52 CryvvIY3.net
>>552
ローカルに対してのハイパーリンクです
index.htmlからhoge.html, fuga.htmlはあっても、hage.htmlが無かったりしたら
それを検出したいです。
孤立しているjpgやgifなどはたくさんありそうなので
そういうのをbashで探すのはもうbashスクリプトの話になりますよね・・

581:login:Penguin
21/12/21 18:09:03.09 svQRlsMH.net
nginxでwebdavやろうと思ってパッケージ作ろうとしてるんだけどうまくいかず、
質問させてください。
ここみながら進めてるんだけどうまくいかない。
URLﾘﾝｸ(qiita.com)
エラー内容
./configure: error: invalid option "/home/don/build/nginx-1.20.2/debian/nginx-dav-ext-module"
make: *** [debian/rules:45: config.status.nginx_debug] エラー 1
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
これはどうすればいいですか？

582:login:Penguin
21/12/21 18:20:03.06 6V4gTjpz.net
>>557
--add-module=
を付けてないとかは流石にない？

583:login:Penguin
21/12/21 19:07:08.36 svQRlsMH.net
>>558
つける場所がよくないのか...と思って確認したらスペース入ってました！！
--add-module= /home...
になってたのでスペース削除したらうまくいきました。
ありがとうございます！

584:login:Penguin
21/12/21 20:49:40.88 9ROmdoHL.net
メッセージ読めば何を間違ったのかすぐに判ると思うのだが
そういう時代になったんだろうか

585:login:Penguin
21/12/21 21:17:47.06 LHeFAY0y.net
>>560
出来合いのものや野良サイト情報をそのまま使用しながらドキュメントも出力メッセージも読まず素人掲示板で質問するのが今のトレンド

586:login:Penguin
21/12/21 21:27:57.72 kYsTj4+3.net
良い時代になったものです。

587:login:Penguin
21/12/21 21:42:51.99 CoKQSK00.net
キモ

588:login:Penguin
21/12/21 22:08:21.39 4Lslsf/v.net
arecordって2GB以上の録音できないんでしょうか?
もっと長く録音できるコマンドはないでしょうか?

589:login:Penguin
21/12/21 22:31:47.03 9r0l0Tzm.net
>>561
Linux板に集う俺らただクレクレ乞食はそんな感じだからな
 >>560
出来ることがコピペ程度のただクレクレ乞食に、そんなすごいことは不可能。
ただクレクレ乞食はコピペものを自分でちょっと変更することすらできない
(妄想で適当にいじる感じに変更）レベル
そんなだから、掲示板で助けてとなる

590:login:Penguin
21/12/21 22:35:30.52 9r0l0Tzm.net
そんな人がnginxでwebdavってすごい
まぁ、Btrfsの人のようなすごすぎな人がいるぐらいだからな

591:login:Penguin
21/12/21 22:41:38.28 LG40fTb8.net
それ絶対褒めてないだろｗ

592:564
21/12/22 02:31:20.58 zh3b5k/G.net
2GBの制限ってwavの仕様のようです
長時間録音しつつそれをパイプでoggencに流して
エンコしたいのですが何か上手い方法はないですかね?
arecordのwav録音だと2GBで自動的にファイルを変えてくれるので
あとでバッチ処理でエンコすることはできるのですがダサい

593:login:Penguin
21/12/22 02:51:31.54 6MLbEeeX.net
>>564
arecord使ったことないけど、”arecord 2GB” でググると
1) ファイルサイズ（オフセット）を64bitにして再コンパイル
or
2) データを標準出力に流してそれをファイルにリダイレクト
って出てきたが。

594:login:Penguin
21/12/22 02:54:46.63 6MLbEeeX.net
またまたググるとWAVは4GBって出るな。32bit符号なし整数ということで。

595:564
21/12/22 03:08:51.06 zh3b5k/G.net
>>569
2)はやりましたが勝手に終了します
恐らくarecordが2GB吐いたところで終了してると思います
ソースを見ましたがwavの仕様でmax_filesizeが2147483648LLとされていますので
wavではなくrawでoggencに流してみようと思います

596:login:Penguin
21/12/22 08:36:49.41 yu8ibXIN.net
>>566
> Btrfsの人のようなすごすぎな
こんなの全然すごくない
近い将来もっと簡単に扱える日が来ると予想している
まさか嫌味でそう書いてるわけじゃないだろうからな

597:login:Penguin
21/12/22 09:18:49.63 XRS8c6H/.net
全発言が嫌味と考えた方がよほど得心が行くのだがｗ
クレクレ君は間違った方に誘導して暴走させとけばいいよｗ

598:login:Penguin
21/12/22 09:22:30.41 yu8ibXIN.net
明らかに荒らしに見えるやつに敢えてきちんと教えようとしていた理由がまだわからないのかな

599:login:Penguin
21/12/22 09:37:48.42 XRS8c6H/.net
好きなだけ暴走させとけばいいんだってｗ
意固地になってるだけの我儘こどおじに構ってる暇はない

600:login:Penguin
21/12/22 09:43:42.86 yu8ibXIN.net
それはそれで貴方のやり方だから仕方無いな
いつの日か今よりクリーンなスレになるといいね

601:login:Penguin
21/12/22 09:53:35.57 XRS8c6H/.net
無駄な努力を続けようが続けなかろうが、有為な差はないよｗ
まあ頑張ってｗ

602:login:Penguin
21/12/22 09:59:11.03 yu8ibXIN.net
あの程度で頑張っていた様に見えていた上にいちいち嫌味含みなんですね
頑張らなくてはならないのは貴方だと多くの人に見えている事でしょう

603:login:Penguin
21/12/22 10:50:40.88 XRS8c6H/.net
荒らしの相手をするのは頑張ることだと思うけどｗ
メディアが壊れてるのと、壊れて欠損した情報を修復すること/修復可能に構成することは違うんだよｗ

604:login:Penguin
21/12/22 11:05:07.41 0UcK8M3p.net
>>556
最後の2行がわからないが、ハイパーリンクだけ抽出できればいいのね？

605:login:Penguin
21/12/22 11:09:27.97 0UcK8M3p.net
>>568
環境、打ってるコマンド、エラーメッセージ

606:login:Penguin
21/12/22 11:18:39.29 ryDP9XlY.net
ここはUbuntuスレの屁理屈エアプ爺(b8-)のスレ

607:564
21/12/22 13:42:15.88 zh3b5k/G.net
>>569,570,581
当方の環境は64bitなのですが2GBの制限はwavの仕様のようです
aplay.c（= arecordのソース）の以下の構造体の
下から3行目の 2147483648LL が原因で
これはwavの仕様ですから変えないで対処することにしました
static const struct fmt_capture {
　　　　void (*start) (int fd, size_t count);
　　　　void (*end) (int fd);
　　　　char *what;
　　　　long long max_filesize;
} fmt_rec_table[] = {
　　　　{ NULL, NULL, N_("raw data"), LLONG_MAX },
　　　　{ begin_voc, end_voc, N_("VOC"), 16000000LL },
　　　　/* FIXME: can WAV handle exactly 2GB or less than it? */
　　　　{ begin_wave, end_wave, N_("WAVE"), 2147483648LL },
　　　　{ begin_au, end_au, N_("Sparc Audio"), LLONG_MAX }
};
結局wavからrawに変えたらうまいこといきました

次ページ