The attached patch sets the "size" for the /proc/PID/fd/N entries
to the current file position (file->f_pos).
In proc_lookupfd(), I fill inode->i_size with file->f_pos. Then
in pid_fd_revalidate(), I refresh it again.
I would find this useful to be able to tell, for example, how far
a large outgoing SMTP transfer has got (so I can avoid rebooting
if it's almost finished), or how far a customer download from our
FTP server has got to.
Was there any particular reason for fixing the "size" of these
files at 64? Are there any tools that depend on this?
Patch is against 2.5.63.
Later,
Kenn
--- /home/kenn/linux-vax/lxr/2.5.63/src/fs/proc/base.c Tue Feb 18 00:25:22 2003
+++ base.c Mon Mar 3 19:55:15 2003
@@ -819,8 +819,11 @@
atomic_inc(&files->count);
task_unlock(task);
if (files) {
+ struct file *f;
read_lock(&files->file_lock);
- if (fcheck_files(files, fd)) {
+ f = fcheck_files(files, fd);
+ if (f) {
+ dentry->d_inode->i_size = f->f_pos;
read_unlock(&files->file_lock);
put_files_struct(files);
return 1;
@@ -926,7 +929,7 @@
read_unlock(&files->file_lock);
put_files_struct(files);
inode->i_op = &proc_pid_link_inode_operations;
- inode->i_size = 64;
+ inode->i_size = file->f_pos;
ei->op.proc_get_link = proc_fd_link;
dentry->d_op = &pid_fd_dentry_operations;
d_add(dentry, inode);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:22 EST