[DragonFlyBSD - Submit #3272] (Resolved) fstat: Show offset for device files too.

[bugtracker-admin at leaf.dragonflybsd.org]

Issue #3272 has been updated by dillon.

Status changed from New to Resolved

I think its reasonable.  I've committed the addition of the offsets and the source code cleanups.  I also made some more involved formatting changes to alignments related to long filenames that should help make the output more readable.

-Matt

----------------------------------------
Submit #3272: fstat: Show offset for device files too.
http://bugs.dragonflybsd.org/issues/3272#change-14080

* Author: falsifian
* Status: Resolved
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch changes fstat to print, e.g, "da0:42" instead of just "da0"
if a process has /dev/da0 open at offset 42.

Tested minimally: I just wrote wrote a program that seeks to offset 42,
then ran fstat on it. Output:

root at copter-dfly:/usr/src/usr.bin/fstat # ./fstat -p6527
USER     CMD          PID   FD PATH               INUM MODE           SZ|DV R/W
root     f           6527 root /                     1 drwxr-xr-x         0  r
root     f           6527   wd /home/falsifian/tmp  23445 drwx------         0  r
root     f           6527 text /home/falsifian/tmp/f 301743 -rwxr-xr-x  0  r
root     f           6527    0 /dev/pts/3         1402 crw-------     pts/3:13384 rw
root     f           6527    1 /dev/pts/3         1402 crw-------     pts/3:13384 rw
root     f           6527    2 /dev/pts/3         1402 crw-------     pts/3:13384 rw
root     f           6527    3 /dev/da0           1361 crw-r-----       da0:42  r

(I wanted this when I first installed DragonflyBSD yesterday. I was
trying to figure out why newfs_hammer2 was stuck, and this might have
helped me narrow down the possibilities by checking whether the offset
was changing very slowly vs. not at all.)

Some notes / questions:

- fst.offset generally seems to come from the f_offset field of a
  struct file. I am not familiar with that struct. It would be good if
  someone who knows more could confirm my assumption that f_offset is
  at least never going to be uninitialized garbage.

- For regular files, it looks like the size is no longer printed at all
  since commit afdbde1b changed it to offset. Was that intentional? At
  least the man page should be updated. (I'm happy to give that a try.)

- Should the indentation fix have been a separate commit? (For future
  reference, at least.) I'm normally pretty pedantic about separating
  commits, but didn't want to annoy anyone.

---Files--------------------------------
0001-Print-file-offset-for-device-files-too.patch (973 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account