On 25/02/2013 09:14 AM, scott wrote:
> Funny story, interesting that Linux works that way - I wouldn't have
> known that (but then it took me almost a week to get my bitTorrent
> client write access to an external hard drive under Linux).

Yeah. In the old days of Unix, there was a folder named /dev, and you 
used to run a command called mknod ("make node") which makes "files" 
which are really just ID numbers that tell the Unix kernel to access 
device X on bus Y. When you access, say, /dev/sda, you're really 
accessing the harddrive.

Windows does a similar thing, except it uses \\?\PhysicalDisk0 as the 
name. And this "file" exists if and only if disk 0 is actually plugged in.

Linux now uses a system called UDev. Instead of the OS installer running 
mknod to generate device nodes for every device that could ever be 
plugged in, the actual /dev folder is empty. The UDev software then 
dynamically creates the appropriate device node when I device is plugged 
in, and deletes it when the device is unplugged again. In this way, only 
nodes for devices that actually exist show up.

This is all very useful. But file redirection is such that if you 
redirect to an existing file, it is overwritten (the behaviour we want 
for our disk image), but if the file does /not/ exist, it gets created. 
And /dev isn't special; it's just a normal folder. The name /dev/sda is 
also not special; it's just a regular file.

All of this makes perfect sense really. It's just that if you tried this 
on Windows (i.e., tried to create \\?\PhysicalDisk7, say) it would tell 
you to go away and die. Linux, on the other hand, lets you do it just 
fine...

>> Fortunately, the fix is very simple. You just need to add a check for
>> the possibility of there being zero devices.
>
> I guess you can use this as a lesson to try and dream up some more
> possible failure modes (eg something else uses up disk space whilst you
> are installing, or ...). It only takes a half hour session and you might
> be surprised what other things you can't handle.

Oh I'm *sure* there must be other things that could fail. If the disk 
was scratched I'd expect some non-deterministic yet spectacular failure 
(not much we can do about that), if the target drive has bad sectors 
that'll probably silently fail too, pressing Ctrl+C will probably break 
something...

> Also it would seem to me to make sense to have a "catch all" type check
> at the end of the installation (eg count folders/files or file sizes or
> md5 on the supposedly installed folder) to really be 100% sure the
> installation worked. At least then if it fails for some crazy reason
> you'll catch it.

Fortunately, the install happens running under a Linux OS that I built. 
There are no other user applications running, and the user shouldn't be 
able to start any. (There's only one text terminal open, and you can't 
open any others.) But we'll see...

Post a reply to this message