Custom Error Type for Unpartitioned Block Device

[johnnybubonic]

First off, fantastic library. Immensely useful.

I have discovered... well, I guess it could be considered a bug.

If one has a device that is unpartitioned, calling (disk.Disk).GetPartitionTable() will result in an error of unknown disk partition type.

Now, there's nothing terrible about this behavior in and of itself; one would not expect that method to return a valid partition.Table.

However, it is currently not possible to determine that the block device actually has no partition table, or if it's simply an unsupported partition table type (as the error message suggests).

In the former case, one would know that the disk is either brand new or has had its partition table cleared, and either way it can be safely partitioned (as use-case appropriate, of course).
In the latter case, one would not want to partition the disk to avoid risking data destruction (and I don't think testdisk supports the more... exotic table formats).

The difficulty, however, is knowing if a table actually is present but invalid/unknown or if there actually is no partitioning.

Given that most partition table formats that I know of at least write SOME data near the beginning of a block device - within the first 4 MiB or so, to be incredibly generous - I suspect that wouldn't be a terribly difficult thing to determine.

To get to the point, however, in the case that no partitioning data is found on a device, either

• a defined error (e.g. partition.ErrNoTable) should be returned or
• the returned partition.Table should be returned nil but no error should be raised

As it stands, since a generic error is returned (and as an *errors.errorString, because it has no constant/variable or type associated with it and is simply fmt.Errorf'd), it is impossible to determine this condition.

[deitch]

First off, fantastic library. Immensely useful

Thanks. And the funniest thing is, it never joined the original purpose for which it was built. But it has had many other good uses.

I am not sure exactly what you are proposing. If it is that, when it cannot find a partition table it understands (currently GPT or MBR), it should not return a generic error, but rather a special error type here, then sure. That makes sense, happy to take a simple PR for it.

If you are proposing that it should try and detect the other partition table types, and return different kinds of errors:

• GPT - return the table
• MBR - return the table
• Other partition type that it can recognize - return an error of type ErrUnsupportedTable ("I found a table I know about but do not support")
• No recognized partition - return an error of type ErrNoTableIdentified ("I found no table I know about")

That makes sense, too, but it requires a lot of work. I am happy to have PRs for it.

[johnnybubonic]

Apologies for not being very clear but you got the idea, yep.

I'll submit a PR in a bit. It may be a little more complex than may be expected, but I'll explain more in the PR - I think I can design it such a way that additional detection for unsupported table types can be added incrementally without breaking API compat.