Unable to delete dev/{fd|pts} in jail

Can you delete files in /dev/ or /dev/fd/ or /dev/pts/ in a normal install, not in a jail?
Notice that I prefixed dev with a slash in the line above, and postfixed things that are directories with a slash.

Look at mount: Is /dev/ a normal file system? Is /dev/fd/ a normal file system? Can you create and delete things in there?
 
ralphbsz said:
Can you delete files in /dev/ or /dev/fd/ or /dev/pts/ in a normal install, not in a jail?
Notice that I prefixed dev with a slash in the line above, and postfixed things that are directories with a slash.

Look at mount: Is /dev/ a normal file system? Is /dev/fd/ a normal file system? Can you create and delete things in there?
Click to expand...
/dev/ and /dev/fd/ looked formal and the directories in /usr/jail/failx/dev/ may well have been linked. I don't really know my way around jails.

I found that after a reboot I was able to delete these directories wthout any problem.
 
balanga said:
/dev/ and /dev/fd/ looked normal formal and the directories in /usr/jail/failx/dev/ may well have been linked.
Click to expand...

Sorry to tell you, but on a normal FreeBSD install, /dev/ and /dev/fd are not a normal file system; they simply reflect the devices the kernel sees, and you can not create files in there. Here is a quote from the mount output on my machine:
Code: 
devfs on /dev (devfs, local, multilabel)
fdescfs on /dev/fd (fdescfs)

The semantics of deleting entries in /dev/ is odd, and the semantics of creating them even more odd. I think what happens when you delete something in /dev/ is that the underlying device continues to exist in the kernel, but becomes inaccessible from user space (simply due to a lack of a way to find it). If a device entry is open, it is not deletable. You can manually recreate entries using mknod, but that only works (and is only sensible) for devices the kernel knows of, and that have previously had their /dev/ entires deleted manually. I hope I have that more or less correct, haven't looked at the implementation in a while. For /dev/fd/ it gets even more odd, since it reflects the environment of the current process; so one process's view of /dev/fd doesn't have to agree with the one other processes see. Deleting that directory does not really affect the system, it may just break user space programs.
 
You must log in or register to reply here.
Back
Top