> I've been having a problem in recent kernels (1.3.30-32, don't know about
> older ones) with the process /fd entries in /proc. All the fd's show
> up in ls, but they can't be written to or read from. Bash gives "no
> such file or directory"
Try this patch on for size. The basic problem is that do_open() in
fs/open.c was reordered in a more sane way. This patches against 1.3.32.
--- fs/proc/link.c Sat Feb 5 18:06:45 1994
+++ fs/proc/link.c.NEW Sat Feb 5 18:11:03 1994
@@ -56,26 +56,13 @@
NULL /* permission */
};
-/*
- * This open routine is somewhat of a hack.... what we are doing is
- * looking up the file structure of the newly opened proc fd file, and
- * replacing it with the actual file structure of the process's file
- * descriptor. This allows plan 9 semantics, so that the returned
- * file descriptor is a dup of the target file descriptor.
- */
static int proc_fd_dupf(struct inode * inode, struct file * f)
{
unsigned int pid, ino;
- int i, fd;
+ int i;
struct task_struct * p;
struct file *new_f;
- for(fd=0 ; fd<NR_OPEN ; fd++)
- if (current->files->fd[fd] == f)
- break;
- if (fd>=NR_OPEN)
- return -ENOENT; /* should never happen */
-
ino = inode->i_ino;
pid = ino >> 16;
ino &= 0x0000ffff;
@@ -92,7 +79,17 @@
return -EPERM;
new_f->f_count++;
- current->files->fd[fd] = new_f;
+
+ f->f_mode=new_f->f_mode;
+ f->f_pos=new_f->f_pos;
+ f->f_flags=new_f->f_flags;
+ f->f_reada=new_f->f_reada;
+ f->f_owner=new_f->f_owner;
+ f->f_inode=new_f->f_inode;
+ f->f_op=new_f->f_op;
+ f->f_version=new_f->f_version;
+ f->private_data=new_f->private_data;
+
if (!--f->f_count)
iput(f->f_inode);
return 0;
-Nat