On 22/05/2020 12:15, Steven D'Aprano wrote:
On Fri, May 22, 2020 at 08:09:29AM +0000, Steve Barnes wrote:
Unfortunately we have no control over where the tests may be run – if run on Windows from the C: drive it could potentially brick the entire machine, (which of course some people might consider a bonus of course). I'm rather shocked to learn that (allegedly?) you can brick modern Windows by filling the drive up. If this was Windows 95 I might believe it, but Windows 7 or 10? Have you confirmed this or is it just a guess?
As for strategies for the test... you could write the test to skip on Windows. Using `unittest`:
@unittest.skipif(os.name == 'nt', 'dangerous to run on Windows')
Does Windows have the capacity to create a file system on the fly and then mount it, as we can do in Linux?
# Untested. dd if=/dev/zero of=/tmp/disk count=2048 mkfs.ntfs -v Untitled /tmp/disk sudo mount -t ntfs /tmp/disk /mnt/
In pseudo-code:
- create a temporary file of 2048 bytes; - write a NTFS file system in that file; - mount that file system somewhere so it is visible;
So have the test create a new file system on the fly, cd into that file system, run the test proper, and if it fills up, no harm done.
If you cannot create a file system on the fly, perhaps you can prepare one before hand, manually, as part of the test requirements, and refuse to run if that scratch (pseudo)disk doesn't exist.
I find having a RAM drive is very handy. Could this be another use for it? Rob Cliffe