Comment by anonymousiam | Hacker News Reader

Comment by anonymousiam | Hacker News Reader

Parent Full thread

The various DEC operating systems (RT-11, VMS, etc.) had PIP (Peripheral Interchange Program) which allowed you to copy files to devices (such as a printer). CP/M had PIP, but did not implement the devices in the filesystem, which MS/DOS did. The result of putting specially named files in the operating system was that files were not always files and strange behavior would occur in fringe use cases.

The basename (without the extension) had certain reserved names such as CON, PRN, AUX, PTR, PUN, etc. Originally these names always had a trailing colon to identify them as devices, but MS/DOS dropped that. MS/DOS kept the trailing colons for disk drive identification, but not much else.

This capability could be used to make a batch files (.BAT) without any editor on the system. One could type: COPY CON RUNME.BAT, and then type in the wanted lines of the batch file. The end-of-file character (^Z 0x1A) was the same on CP/M and DOS, unlike (^D 0x04) on Unix.

https://gordonbell.azurewebsites.net/Digital/RT-11%20System%...

>files were not always files and strange behavior would occur in fringe use cases.

coughs in Unix

True, device nodes and other special files exist in Unix, but they are usually contained to special directories.

You can create sockets and fifos anywhere. Device nodes are the only special ones which are generally confined to specific locations.

I think on BSDs at least you can theoretically put device nodes wherever you want (but there’s no good reason not to put them in /dev where everything expects them to be).

I'm pretty sure on Linux too there is nothing stopping you from putting a device node in any directory either. By convention they live in /dev (or its subdirectories), but there is nothing technically enforcing that convention.

(udev assumes they live under /dev. I'm not sure if /dev is hardcoded in udev or configurable. But you don't have to use udev anyway, you can create device nodes manually.)

Yeah, it's just a mknod away provided your filesystem isn't mounted nodev

Running a service inside a chroot might require some combination of /dev/{null,random,console,log} to be present inside the chroot, and bind-mounting /dev exposes the entire underlying system (raw disk nodes) inside the chroot.

So there's actually a good reason for being able to create device nodes outside /dev.

On FreeBSD you can mount devfs but tell it to only expose a subset of the device nodes, for exactly this reason.

Yeah, I used to do this to NFS-export a root filesystem for my diskless Sun-3. The NFS server was running Linux and the Sun was running IIRC NetBSD, so some of the device numbers in the Sun's /dev needed to be different. Pretty rickety setup but it worked okay. I don't recall ever accidentally overwriting my root filesystem or hanging up the modem line by accessing the bogus device nodes.

We actually use this too (https://libguestfs.org/nbdkit-file-plugin.1.html#PARAMETERS with "dir" parameter). It allows you to create a directory of devices to export. Symlinks are supported and generally better though.

From FreeBSD 6.0 onwards, device nodes can only exist in devfs. (Ok, technically you can create them elsewhere, but you can't use them to access devices.)

I see. I’m more familiar with OpenBSD which I don’t think has such a restriction. (Though I could be wrong).

That's why most partitions have the nodev mount option. An (one of the rreasons) why there is pushback on a single big partition for everything.

Should have been more clear. Yes, (at least in Linux) you can mknod a special file anywhere, but the directory hierarchy is taken in context when you open the file. On MSDOS, you can open AUX or CON in any directory, even though no such named file exists anywhere in the filesystem. THAT is a poor implementation, and would probably be considered a bug by most developers if it were offered as a solution today.

You know… it was called QDOS for a reason.

There wasn't directories in the first release of DOS. So I can forgive those special devices being location agnostic. However removing the device suffix (the colon) is really what causes this to be a bug.

You either have persistent files with special attributes that identify it as a device, or you namespace your devices with characters that cannot be used in a file name. But you don't allow your devices to be valid file names and have them invisible on the file system.

> However removing the device suffix (the colon) is really what causes this to be a bug.

I never thought about it, but when you consider ‘:’ as the device suffix, this makes directory structures make more sense to me on Windows.

C:\foo\bar makes more sense to me if it is the ‘C:’ device. Calling it a ‘C drive’ with a separate namespace never made sense to me. Somehow thinking of it the ‘C:’ device in an anonymous global hierarchy makes more sense to me.

Device files require that the mount point allow device files. That's a mount-time option, and "nodev" will prevent this.

You'll still be able to create named pipes (mkfifo), but mknod will fail.

This is handy for filesystems with a poorly developed sense of user ownership and permissions, say, msdos or vfat.

I tend to mount my /tmp space nodev and nosuid, as occasionally you'll find poorly-written, or nefariously-intended programs attempting to do such things there.

The comparison to Unix stumbles because the behaviour of named pipes, Unix-domain sockets, and device special files, in a regular filesystem, is not based on their filename, but on the arguments to mknod(2) at their creation.

It goes back to version 2 where there was a planned merge of Xenix and dos.

You can even get it using the Unix path slashes in the 2.11 source code.

Reply on news.ycombinator.com