Ronald Klop <ronald-li...@klop.ws> wrote: > Wow, > > diskinfo.c has explicit support for regular files: > > But I would not know the proper use case for that related to the name of the > tool.
I guess reading an imagefile, without needed to make an md device of it first, I guess.... But hardly a "must have", in my opinion. Howerver, what's even worse is that it first looks for <device-file> in the current directory, and if that fails, it then tries /dev/<device-file> And to compound that, the screen output doesn't show whether it's matching ./<device-file> or /dev/<device-file> leading easily to the confusion Pete encountered. I think it should either treat the provided <device-file> as an unaltered filepath (i.e. "xxx" refers to file "./xxx", "/dev/xxx" refers to file "/dev/xxx" etc.) OR have it anchored to /dev unless a path is specified (i.e. "xxx" refers to "/dev/xxx", "./xxx" refers to "./xxx", "/tmp/xxx" refers to "/tmp/xxx" etc.) but the current ambiguous method is the worst of both worlds. Still, at the very least, the file being accessed should be unambiguously displayed in the output. | jamie@thompson% pwd | /tmp | | jamie@thompson% dd if=/dev/ada0 bs=1m count=10 of=ada1 | 10+0 records in | 10+0 records out | 10485760 bytes transferred in 0.036465 secs (287554872 bytes/sec) | | jamie@thompson% diskinfo ada1 | ada1 512 10485760 20480 4096 0 | | jamie@thompson% rm ada1 | | jamie@thompson% diskinfo ada1 | ada1 512 1050214588416 2051200368 0 0 2034921 16 63 NASTY! Cheers, Jamie
