タグ付けされた質問 「filesystems」

もちろん、ファイルが空かどうかをテストする標準的な方法はですがtest -s FILE、クライアントの1人が次のようなテストを含むスクリプトを受け取りました。 RETVAL=`ls -s ./log/cr_trig.log | awk '{print $1}'` if test $RETVAL -ne 0 then echo "Badness: Log not empty" exit 25 fi サプライヤからは、テストした2つの環境で動作するという主張がありました。言うまでもなく、テストした2つの場所の両方でひどく失敗しました。 それで、私は興味を持ちました。ない場合はls -s、印刷0空のファイルのため？ これはこれまでの私の発見です： Linux上のGFS：4 Linux上のext4：0 Solaris上のZFS：1 SolarisのUFS：0 AIX上のjfs：0 HP-UX上のVxFS：0 HP-UX上のHFS：0 Mac OS X上のHFS：0 ネットワーク化されたファイルシステムについてはまだ調べていません。 質問：スクリプトが間違っていることを他の人にエレガントに説明するにはどうすればよいですか？ 私の意見では、「正しい」バージョンは次のようになります。 if test ! -s ./log/cr_trig.log then echo "Badness: Log …

13 filesystems  shell-script  ls  compatibility 

UNIXシステムに移行したいくつかのファイルのアクセス許可を大量に再帰的に変更していました。それらをug + rwに変更しましたが、サブディレクトリを横断できないことがわかりました。私はマニュアルページを見て、chmodディレクトリを除外することについて何の説明も見なかったので、私は少しグーグルで調べ、人々findがディレクトリのパーミッションを再帰的にユーザーとグループの「実行」するように変更していたことがわかりました。私はそれをしてから、それらを調べることができました。 しかしchmod、ファイルを読み取り/書き込みに再帰的に変更し、ディレクトリをトラバースできないようにするには、この検索を実行できる必要があるように思えました。これを「正しい」方法で行ったか、それとももっと簡単な方法がありますか？

13 filesystems  permissions  find  chmod 

私は少し迷いましたが、完全なディスク暗号化のためにどのテクノロジーを選択すべきかわかりません。そこにある情報がまだ最新かどうかを見分けるのは困難です。これに対する現在のベストプラクティスソリューションはありますか？

13 linux  security  filesystems 

このようなソケットファイルの場合： # ls -alti socket 14112 srw------- 1 root root 0 Nov 15 20:03 socket # cat socket cat: socket: No such device or address catここではコマンドは役に立たないので、ソケットファイルに関する詳細情報を取得する方法はありますか？どのポートでリッスンしているかなど？等

13 linux  filesystems  socket 

これに似たファイルシステムオブジェクトを作成する方法はありますか？ mknod files p cat file1 file2 ... fileN > files しかし、それがまるで通常のファイルであるかのように、それを捜すことができるように？

13 filesystems  files  cat  fifo 

関連した本。 OSスイッチを利用してBTRFSにアップグレードしたいと思います。 BTRFSは多くの機能を提供すると主張しています（データ損失の回復力、RAIDの場合の自己修復、メタデータとデータのチェックサム、圧縮、スナップショット）。しかしfsync、dpkg（私が知っeatmydataている、くだらないapt-btrfs-snapshotプログラム）などの集中的なプログラムで使用すると、遅くなり、RAIDをセットアップしません：p。 EXT4は、メタデータのチェックサムのみを許可し、データを圧縮しません。 6年で、HDDが破損したため（飛行旅行後）、OSを2回再インストールする必要がありました。最初のラップトップを起動不能にし、2番目の破損は、破損したフィルムとOSバイナリのmd5sumチェックのおかげで特定されました。（SMARTはディスクが正常であることを教えてくれます）。ラッピーは現在非常に奇妙に動作します。ハードウェアとソフトウェアのどちらが責任があるのか​​はわかりませんが、ハードウェアが疑われます（フライトの直後にすべてが再び始まりました）。 データ圧縮とチェックサムのため、ラップトップのBTRFSに切り替えることをお勧めしますか、またはEXT4に固執する必要がありますか？ （どの変数と比較してどちらが「最良」であるかは気にしませんが、BTRFSの経験がほとんどないため、フィードバックを希望します） 編集： レッツは、より明確になる：BTRFSはまだ私は、実験としてフラグが設定されている知っているが、SUSEは、それはもういけないと言います。Oracleも同様です（Oracleが誰であるかは知っています）。そして、多くのディストリビューションがすでにインストール用のBTRFSを提案しており、それらのほとんどは今後数か月でBTRFSに切り替えることを計画しています。 2つの事実： 破損したデータのバックアップは価値がありません。なぜ私がわざわざ唯一の人であるように見えるのか分かりません。それは常識ではありませんか？その間： バックアップを行うべきだと言って停止する：私はすでにやっています。 バックアップを暗示するのをやめるだけで、数年分のバックアップを行うためにTBの空き領域を与えてくれる場合を除き、データを安全に保つことができます。 破損したファイル= / => Linuxからの不満。そう： OSが起動しているという理由だけで、システム/データが正常であると想定しないでください。 データの整合性をチェックするために、BTRFSの半分の機能で不便なことになりますが、過剰に設計され肥大化したソフトウェアよりも（メタ）データチェックサムを好むことを理解してください。 どのFSが「優れている」かを尋ねていないので、それはより明確になりましたか？質問は、私が定期的にバックアップを行うことを考えると、BTRFSはまだ実験的すぎてデータの整合性チェック機能に使用できないのですか、それともEXT4に固執するべきですか？

13 linux  filesystems  ext4  btrfs 

ファイルが破損しているかどうかを確認する一般的な解決策はありますか？たとえば、ビデオファイルが不良であるか、圧縮ファイルが破損しているかなどです。

13 filesystems  corruption  checksum 

特定のFILEを含むファイルシステムのマウントポイントをすばやく見つける方法を探しています。以下の私の解決策よりも簡単または直接的なものはありますか？ df -h FILE |tail -1 | awk -F% '{print $NF}' | tr -d ' ' 同様の質問「ディスクがマウントされている場所を確認するコマンドはありますか？」は、現在のディスクのデバイスノードを入力として使用し、ディスクからの任意のファイルではありません...

13 shell  filesystems  mount 

LinuxをUSBドライブにインストールすることを計画していますが、最高のパフォーマンス（全体的な応答性）とドライブの寿命を実現するためにドライブをフォーマットするためにどのファイルシステムを使用すればよいか迷っていました。

13 linux  filesystems  usb 

Linuxは多くのファイルシステムをサポートしています（例：ext3、NTFS、FAT32など）。 次の図は、Linuxがプロセスがファイルにアクセスする方法を示しています。 そのため、プロセスread()がファイルを読み取るためのシステムコールを呼び出し、VFSレイヤーにアクセスし、VFSレイヤーがファイルのパーティションのファイルシステムに基づいてアクセスするファイルシステムドライバーを決定すると仮定します。読み取りが常駐します。 Linuxは（例：アクセスファイルには多くのシステムコールを提供しread()、write()、rename()、など）。 今read()とwrite()とrename()、Linuxのサポートされているすべてのファイルシステムに関する作業。 ただし、一部のファイルシステムにのみ存在し、他のファイルシステムには存在しない特定の機能があります。たとえば、NTFSファイルシステムでは、ファイルのアーカイブビットを設定できますが、ext3ファイルシステムでは設定できません。 さて、私の質問は、Linuxがサポートするファイルシステムのすべての機能にアクセスするためのシステムコールはありますか？たとえば、Linux にはNTFSファイルシステム上のファイルにアーカイブビットを設定するシステムコールがありますか？

12 linux  filesystems 

この質問は、先日、ファイル名に関して意見のあるフレームワークに依存する開発プロジェクトに取り組んでいたときに思いつきました。フレームワーク（ここでは無関係）は、大文字が最初のファイル名を表示することを望んでいました。これは私に考えさせられました。 大文字と小文字を区別しないファイルシステムで、extFATまたはHFS +（具体的には大文字と小文字を区別しない）と言うと、ファイルシステムはファイル名の大文字と小文字の両方の同じファイルへのアクセスをどのように提供します。 例えば： $ cd ~/Documents $ pwd /home/derp/Documents $ cd ../documents $ pwd /home/derp/documents $ cd ../docuMents $ pwd /home/derp/docuMents $ cd ../DOCUMENTS $ pwd /home/derp/DOCUMENTS $ cd ../documentS $ pwd /home/derp/documentS これらのコマンドはすべて同じディレクトリに解決されます。この動作、具体的pwdにbashはこの場合の関数からの出力は、私が見たいと思うものを私に見せているだけですか？ もう一つの例： $ ls ~/Documents Derp.txt another.txt whatThe.WORLD ここでのファイルシステムは、ユーザーまたはプログラムによって作成された元のファイル名のケースを報告します。 正しい大文字と小文字のASCII文字の任意の組み合わせでアクセスできるように、ファイルシステムスタックのどの時点で、人間が読み取れるファイル名が作成時に保存されますか（大文字と小文字など）。これはどこか正規表現のトリックなのでしょうか、それとも何か他のことが起こっているのでしょうか？ 編集：私が興味を持っている動作は、さらに研究した後、大文字と小文字を区別しないファイルシステムで見つかったようです...

12 filesystems  filenames  case-sensitivity 

VMのパフォーマンスの問題に遭遇した後、システムをbtrfsからext4に移行しました。私のラップトップには2台のハードドライブがあります。ホームパーティションを正常に移動しましたが、使用した手順と同じ手順がルートに対して機能していません。 これまでの進捗： 私がしましたdd「から、私のルートパーティションはd /dev/sda3に/dev/sdb3。/etc/fstab次のように変更しました。 $ cat /etc/fstab # # /etc/fstab: static file system information # # <file system> <dir> <type> <options> <dump> <pass> # UUID=95f13c34-96ca-49e3-bcb2-ff594df31506 /dev/sdb3 / btrfs rw,noatime,ssd,space_cache,discard 0 0 # UUID=0fe04f59-599f-41e2-ac30-2ad0f17a9727 /dev/sda2 /boot ext2 rw,relatime 0 2 # UUID=44741e0f-924a-4841-80ef-2132bef84182 /dev/sda4 /home ext4 rw,noatime,discard 0 0 実行しsudo mkinitcpio -p …

12 filesystems  boot  partition 

もしそうならls -1 target_dir | wc -l、ディレクトリ内のファイルの数を取得します。これは少し面倒です。もっとエレガントで簡潔な方法はありますか？

12 ubuntu  command-line  filesystems 

を使用してコピーする場合cp、明示的な場合でも拡張属性は保持されません cp -a --preserve=all /source /dest または cp -a --preserve=xattr /source /dest 同じことはrsync、つまり rsync -aq -A -X --delete /source /dest ただし、宛先ファイルシステムでは、（を使用してchattr）拡張属性を手動で作成できます。これは、ターゲットファイルシステムがxattrをサポートすることを意味します。 なぜ私は保存することができませんxattrでcpかrsync？ 追加情報： ソースとターゲットの両方のファイルシステムはext4です ソースとターゲットの両方のファイルシステムはローカルです（nfsではありません） Debian Wheezyを使用しています

12 filesystems  rsync  cp  xattr 

私が知ったように、umaskを使用する場合、ファイルに与えることができる最高の許可は666です。これはによって行われumask 0000ます。これは、デフォルトのファイル作成許可のためです。これは、私が知っているすべてのシステムで666のようです。 ファイルについては、コンテンツを表示するための実行権が必要です。 しかし、なぜ666のデフォルトのファイル作成許可を制限するのですか？

12 permissions  filesystems  files