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


5
ext4の誕生は空です
のBirthセクションを読んでいただけstatで、ext4がサポートしているように見えますが、作成したばかりのファイルでも空のままです。 ~ % touch test slave-iv ~ % stat test.pl slave-iv File: ‘test.pl’ Size: 173 Blocks: 8 IO Block: 4096 regular file Device: 903h/2307d Inode: 41943086 Links: 1 Access: (0600/-rw-------) Uid: ( 1000/xenoterracide) Gid: ( 100/ users) Access: 2012-09-22 18:22:16.924634497 -0500 Modify: 2012-09-22 18:22:16.924634497 -0500 Change: 2012-09-22 18:22:16.947967935 -0500 Birth: …
83 filesystems  ext4  stat 


1
「奇妙なファイル」とは何ですか?
私が使用しているアプリケーションは、このユーザーメッセージで開始されません。 [Errno 13] Permission denied: '/home/sleblanc/.config/app/.config を使用するlsと、ファイルは次のように表示されました。 ?--------- 1 root root 0 Dec 31 1969 .config ファイルでstatを実行すると、次のことがわかります。 % stat .config File: .config Size: 0 Blocks: 0 IO Block: 4096 weird file Device: 2dh/45d Inode: 9799944 Links: 1 Access: (0666/?rw-rw-rw-) Uid: ( 1000/ sleblanc) Gid: ( 1000/ sleblanc) Access: 1969-12-31 19:00:00.000000000 …
38 filesystems  stat 

3
ファイル作成日を取得するLinuxカーネルインターフェイスはまだありませんか?
長い間、Linuxはファイル作成日を気にしませんでした。なぜなら、Linuxが一般的に使用しているファイルシステムはどれもそれらをサポートしていないからです。ただし、現在では、一般的に使用されている2つのファイルシステム(NTFSとext4)の両方でファイルの作成日が記録されています。 statこのコマンドは、しかし、まだ出力Birth: -我々はext4のはのは、使用して日付を作成し、ファイルを保存している見ることができるにもかかわらず、ext4ファイルシステム上にdebugfs -R 'stat <inode_number>' /dev/file_device。 私はこれである理由の中に見たとき、私は他の誰かがすでにいました最近提出され、その上にバグレポートを、とに通じ、応答リンク上流の問題ファイル[単純にその情報を取得するために、現時点でなしのLinuxカーネルインターフェースがある」と述べていること作成日]"。明らかであるように私には注目に値すると思われる、まだの人はその要求されているように、ケースstat年間、ディスプレイにこの情報を(してstat出力しBirth、フィールドを、それは明らかにまだそれをサポートしていないにも関わらず!彼らは見越して、それを追加しましたか?) それでは、ファイル作成日を取得するためのLinuxカーネルインターフェースが現在ないというのは本当ですか?これを実装する計画はありますか?
21 filesystems  stat 

2
OSXでのstatの出力
statコマンドを使用してファイルに関する情報を取得したい。これは私がしました: Josephs-MacBook-Pro:Desktop Joseph$ echo 'hello' > info.txt Josephs-MacBook-Pro:Desktop Joseph$ stat info.txt 16777220 21195549 -rw-r--r-- 1 Joseph staff 0 6 "Dec 21 20:45:31 2014" "Dec 21 20:45:30 2014" "Dec 21 20:45:30 2014" "Dec 21 20:45:30 2014" 4096 8 0 info.txt 3行目と4行目は、私が得た出力です。これは、statコマンドを使用するたびに発生します。一方、インターネット上の誰もが次のようなものを取得します。 File: `index.htm' Size: 17137 Blocks: 40 IO Block: 8192 regular …
15 osx  stat  portability 

1
inotifyは、書き込みの開始時または完了時に通知を起動しますか?
ext3 fs上の通常のファイルを介して通信する2つのプロセス、リーダーとライターを想像してください。Reader IN_MODIFYにはファイルのinotify ウォッチがあります。ライターは、1回のwrite()呼び出しでファイルに1000バイトを書き込みます。Readerはinotifyイベントを取得fstatし、ファイルを呼び出します。リーダーには何が見えますか? Readerがst_sizeファイルに対して少なくとも1000を取得するという保証はありますか?私の実験から、そうではないようです。 Readerが実際にread()1000バイトできるという保証はありますか? これは、真剣にI / Oバウンドボックスで発生しています。たとえばsar、約1秒の待機時間を示します。私の場合、リーダーはを呼び出す前にinotifyイベントを取得してから10秒待ってから、stat結果が小さすぎます。 私が期待していたのは、ファイルの準備が整うまでinotifyイベントが配信されないことでした。私が実際に起こっていると思うのwrite()は、ライターでの呼び出し中にinotifyイベントが発生し、データが準備ができたときにシステム上の他のプロセスで実際に利用できることです。この場合、10秒では十分ではありません。 私は、カーネルが実際に私が推測している方法を実装していることの確認を探しているだけだと思います。また、おそらく、この動作を変更するオプションがありますか? 最後に-この振る舞いを考えると、inotifyのポイントは何ですか?とにかく、イベントを取得した後、データが実際に利用可能になるまで、ファイル/ディレクトリをポーリングすることになります。それをずっとやっていて、inotifyを忘れることもあります。 *** 編集 ** * * さて、よくあることですが、私が実際にやっていることが理解できたので、私が見ている行動は実際に理にかなっています。^ _ ^ 私は実際に、ファイルが存在するディレクトリのIN_CREATEイベントに応答しています。したがって、実際には、ファイルの作成に応答してファイルをstat()しています。必ずしもIN_MODIFYイベントではなく、後で到着する可能性があります。 コードを変更して、IN_CREATEイベントを取得したら、ファイル自体でIN_MODIFYにサブスクライブし、IN_MODIFYイベントを取得するまで実際にファイルを読み取ろうとしないようにします。ファイルへの書き込みを見逃す可能性のある小さなウィンドウがあることを認識していますが、最悪の場合、最大秒数後にファイルが閉じられるため、これは私のアプリケーションでは受け入れられます。
12 linux  files  stat  inotify 


4
特別なデバイスファイルにiノードがあるのはなぜですか?
デバイスファイル自体はファイルではありません。これらは、Unixライクなオペレーティングシステムでデバイスを使用するためのI / Oインターフェイスです。これらはディスク上のスペースを使用しませんが、stat次のコマンドで報告されるようにiノードを使用します。 $ stat /dev/sda File: /dev/sda Size: 0 Blocks: 0 IO Block: 4096 block special file Device: 6h/6d Inode: 14628 Links: 1 Device type: 8,0 デバイスファイルはファイルシステムの物理的な iノードを使用しますか、なぜそれらを必要とするのですか?

5
statを使用してタッチのタイムスタンプを提供する
一部のドキュメントをその場でOCRしようとしています(Windows共有のLinuxコマンドラインから)。OCRのプロセスはfindであり、findコマンドを使用してファイルをループで正しくパイプ処理することで混乱しています。 ただし、変更のために元のタイムスタンプを保持する必要があります。私は現在、以下のようにstatとtouchを使用しようとしています: #!/bin/bash OLDIFS=$IFS IFS=$(echo -en "\n\b") for f in `find /mnt/library/Libra/Libra/Ashfords -name "*.pdf"` do ORIGTS=`stat -c "%Y" $f` sudo /opt/ABBYYOCR9/abbyyocr9 -rl English -pi -if $f -f PDFA -paemImageOnText -pafpr original -of $f touch -t $ORIGTS $f done IFS=$OLDIFS もちろんタッチコマンドは失敗します。コマンドを個別に実行すると、 "stat -c"が次のようになります。 1334758696 それは私が知らない日付のようなものです。近くにいるような気がしますが、日付をタッチフレンドリーなバージョンに変換する方法がわかりません。何かからの秒の形ですか?
11 bash  scripting  stat 

3
stat:ファイルの変更タイムスタンプ
私はstat -f %m .bashrcosx上の.bashrcの変更時間を取得するために使用しています。しかし、ubuntuで同じコマンドを実行すると、エラーが発生します。 stat: cannot read file system information for %m': No such file or directory これを達成するための互換性のある方法はありますか?

4
ファイルが変更されているかどうかを確認する
Linux(現在ext4ファイルシステムを使用している)では、ファイルの内容を読み取らずにファイルの内容が変更されているかどうかをすばやく確認するにはどうすればよいですか? あるstatコマンドが推奨されるアプローチ?私は現在します $ stat --format "%Y" hello.txt その後、同じコマンドで同じ出力が得られるかどうかを確認できます。そうであれば、hello.txtは変更されていないと結論付けます。 私は、より確実にするために、より多くのパラメーターを投入したいと考えています。たとえば、ファイルサイズ、ファイル名などを追加すると、ファイルのさらに優れた「フィンガープリント」が提供されますか? このトピックについて、TrueCryptがメタデータの変更を残さないようにしたためか、以前に使用したTrueCryptボリュームが常に増分バックアッププログラムによって無視されたことを思い出します。によって返されたすべてのデータを変更することは確かに可能だと思いstatます。そのため、ファイルの可能なすべての変更を取得することは保証できません。
10 files  timestamps  stat 

4
ファイルのグループ権限を検査する方法
bashスクリプトからファイルのグループ権限を検査したいと思います。具体的には、ファイルにグループ書き込み可能ビットがオンになっているかどうかを確認する必要があります。 それでおしまい。そのような単純な。しかしながら: 持ち運びにも便利です。 test -w <file グループ書き込み可能かどうかはわかりません。 の出力はls -ld人間にとっては良いですが、スクリプトについてはよくわかりません。技術的にはdrwxrwxr-x、グループビットを抽出するなど、出力を解析できましたが、これは脆弱に思われます。 のインターフェイスstatは、OS Xと他のシステムとの間で完全に互換性がありません。 find <file> -perm ... おそらく答えにはなりませんか?
9 bash  permissions  ls  stat 

3
ファイルブロックサイズ-statとlsの違い
私がするとき、私はそれに気づきました: ls -ls file それは、ブロック数、たとえば8ブロックを提供します。 私がする時: stat file ブロック数が16で、lsで指定された数の2倍であることに気づきました。 私のファイルシステムのブロックサイズは4096です。lsで使用されるブロックの任意の単位は1024であることがわかりました。ブロックを報告するときに、statが512バイトの任意の単位を使用すると言って間違いありませんか? もしそうなら、矛盾の理由はありますか? 私はext4ファイルシステムでUbuntu 11.10を実行しています。

2
FATファイルシステムのファイル作成時間を変更する
マウントされたFAT32ボリューム上のファイルの作成時間を変更する方法が必要です。私のMP3プレーヤーはこの作成時間でソートされたファイルのみを読み取るため、これを行う必要があります。 ファイルのファイル作成時間(touch変更/アクセス時間のように)を設定する方法を見つけることができる場合、簡単なスクリプトでMP3ファイルを正しい順序で(予想どおり、アルファベット順に)読み取ることができます。 しかし、私はまだ解決策を見つけていないので、私の検索は無駄になっています。皆さんが私を助けてくれることを願っています!
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.