|
From: Richard R. <nt...@fl...> - 2002-10-13 23:34:16
|
Hi All, Sorry for the slow reply. Fabio: > Well, it seems logical that the best test is really if windoze accepts > our changes to the FS or not... Absolutely. We should be able to create some basic tools for testing the read-only part in Linux, but we will have to ask Windows if a write was correct. Fabio: > What tests do you guys normally perform? Anton had a very badly fragmented partition which also had sparse and compressed files on it. He took an image of it and he uses that for tesing. The test is simply to md5sum every file on the disk and compare that to a known good set. The first set should test the most vital parts of the driver. Does the module insert/remove OK. Try out some mount parameters. Next I think we need to check that directories can be read correctly. Can we see all the entries (special attention to the first and last files). In addition we should check that filenames in non-Western character sets are handled reliably. Next read a file. We need to test every combination of: Resident file Non-resident file Sparse Compressed Encrypted Each should be read from beginning and special section (e.g. sparse) and end. Then we need to repeat the tests using mmap. (Encrypted files will fail, atm). Finally write to a file. We need to test every combination of: Resident file Non-resident file Sparse Compressed Encrypted carefully checking the end conditions. Then we need to repeat the tests using mmap. Sparse, compressed and encrypted files will currently fail. We should perform each of the write tests in each of NT, 2K and XP. Andrew: > Can switching virtual machines also be [easily] automated? > The only method I can think of is TCP/IP communication saying > things like: "move onto the next test now" and "verify that has > no errors now", etc. I guess it's not too hard, but a bit messy. Szaka: > favouritevm winbox > while (prepare next test) > ssh winbox mount drive > ssh winbox execute test > wait for result or timeout/crash > if (timeout/crashed) > restart favouritevm winbox > else > ssh winbox umount drive Hmm, this is starting to look promising. I found an ssh server for windows (yet to test it): http://www.networksimplicity.com/openssh Andrew: > simple test cases where we can prepare input and expected output > after an operation. The e2fsck unit tests work like this... take a > look! Szaka: > One way could be "embrace, customise, extend" the ext2 test tools. They're certainly a nice source of ideas, but we're limited by the output of chkdsk. We could create a set of tiny test images, as they do and copy then over our test partition. Andrew: > windows might silently fail. > windows might silently correct errors. That's a real worry. Andrew: > diff(1) This could work. Matt Fanto started work on "ntfsinfo". This needs more work, but the idea was to dump ntfs structures in a human-readable format. We may not be able to get enough info from chkdsk, but the ntfsinfo output and diff would be able to tell us everything that changed. Fabio: > ... the ideal scenario is to have the unit testers test individual > functions of the API. I'm not sure this is feasible with this type of > code. Some functions would be good to add specific tests for. "mount", and "umount", obviously. Szaka: > The question is, I think, more like who will do it? Hmm... I'd prefer to not have to do this myself. Most of the tools will only require a knowledge of unix programming, "open file", "write to file", etc. Each program will be very simple. The other tools we'd need are to mount/unmount a volume under windows. This shouldn't be too hard under 2K and XP. I don't have any tools to compile under Windows, so I'll have to delegate this task. Cheers, FlatCap (Rich) nt...@fl... WWW: http://linux-ntfs.sf.net IRC: #ntfs on irc.freenode.net |
