6 ms·
There are two major problems with this: partitions/device-mapper and backwards compatibility. First, partitions inherently overlap the parent block device. You
by Hello71 6y ago
There are two major problems with this: partitions/device-mapper and backwards compatibility. First, partitions inherently overlap the parent block device. You would need to carefully track exactly which portions of the device are in use, or your solution is useless (it doesn't protect /dev/sda when /dev/sda1 is in use) or blocks the vast majority of use cases (/dev/sda2 cannot be used when /dev/sda1 is in use). The same applies for device-mapper, but worse. Secondly, the Linux kernel has a very strong backwards compatibility guarantee. Any change that would break valid (or even invalid) uses will be loudly rejected by Linus. With your idea, many disk management programs will be broken.
- TacticalCoder 6y agoYou could though probably make a wrapper that only kicks in when dd is called from the command line (as opposed to, say, from a script or some GUI program) and asking a confirmation "Do you really want to overwrite your main drive?", without breaking backward compatibility? I have written a few wrappers like that on my own system preventing me from making a few common mistakes of mine (like scp'ing a file locally to a filename ressembling an IP address instead of on a remote server ;)
- Hello71 6y agosure, but it'd be less confusing to just make it a new command. you could add features like invoking lsblk with a sensible set of flags.
- jschwartzi 6y agoExcept the whole point of the wrapper is to protect people who are ignorant of alternatives from overwriting their main system drive by carelessly typing /dev/sda when they mean /dev/sdb on their local system. So making a new command and socializing it doesn't actually improve the situation at all.
- pilsetnieks 6y agoWhen it's a new command it doesn't solve the problem of newbies and 3 decades of old tutorials, which was the comment that started this thread.
- skissane 6y ago> partitions inherently overlap the parent block device. You would need to carefully track exactly which portions of the device are in use, or your solution is useless (it doesn't protect /dev/sda when /dev/sda1 is in use) I think this could be addressed by the idea of a "parent block device". So /dev/sda1 is mounted, then its parent /dev/sda would be classified as mounted, but /dev/sda2 would not be (assuming there is no partition mounted there.) I'm sure one could work something out that would work for device-mapper, LVM, etc as well > Secondly, the Linux kernel has a very strong backwards compatibility guarantee What about a sysctl knob? Turn it on, you get this new behaviour, turn it off, you get the backwards compatible behaviour. Each distribution can decide what to default it to. If it defaults to off in Linus' tree, that should satisfy his backwards compatibility concerns. > With your idea, many disk management programs will be broken. There would need to be some escape hatch, e.g. an ioctl, to allow unsafe writes. And disk management programs would have to be patched to invoke that escape hatch. A distribution wouldn't ship the sysctl as defaulting to on until it had patched all the disk management programs in that distribution. And, if you download a third-party tool, either its developers have patched it to use that ioctl, or else you can just temporarily turn off the sysctl knob while you use it.