System.IO.FileSystem tests fail all over with temp on Fat32 #66544
Comments
dotnet-issue-labeler
bot
added
area-System.IO
untriaged
|
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsSome tests in System.IO.FileSystem are conditionalized on being run on a FAT32 volume (specifically, that temp is on FAT32 -- where the repo is is not relevant) So I'd expect this library to pass when temp is on FAT32. I changed TEMP and TMP env variables to a FAT32 volume and ran this test library. Unsurprisingly because this hasn't been done in a long time and there are many failures, below are the various failure modes. Presumably we want to fix this so that we have some way to confirm that our IO APIs work fine on FAT32. (In an ideal world, all our tests that use the file system would be known to pass on FAT32, but minimally our IO tests would) The failures below are
failuresat System.IO.Tests.File_Copy_str_str_b.Copy(String source, String dest) in D:\git\runtime\src\libraries\System.IO.FileSystem\tests\File\Copy.cs:line 262 at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize) at System.IO.FileSystem.SetLastWriteTime(String fullPath, DateTimeOffset time, Boolean asDirectory)
|
|
It occurs to me that these tests of course ought to pass on Linux against FAT32. |
danmoseley
added
good first issue
|
Maybe we could put a virtual hard drive/ISO file in runtime-assets that has a FAT32 file system and have a test leg use a mounted copy of that? |
|
That's an interesting idea. I also notice ramdisk.inf/ramdisk.sys in the Windows directory, which may be an old SDK sample. didn't try to get it to work. |
|
@danmoseley I totally agree with you, I've added this issue to #54495. |
adamsitnik
removed
the
untriaged
|
We could create a virtual filesystem for NTFS & FAT32. |
|
I should add that I don't think this is an urgent/critical problem. There have been very few filesystem specific bugs that I recall (eg this one), FAT32 is not the only other interesting filesystem, and despite these tests apparently not having run for a while, all the failures appear to be simply test issues. If there's a cheap way to work in a new filesystem into the matrix, that would be nice, but not vital and likely not worth doing if it slowed the tests down or made them more fragile. |
|
Forgot to reset the variables so I accidentally ran all the tests on FAT32. Not much else of note
Both 1 and 2 are OS supplied messages, so on Linux against FAT32 they will be some other message. Not surprisingly most of System.IO.FileSystem.AccessControl.Tests failed. Nothing of concern though. |
FAT32 doesn't support symlinks, only NTFS if you are on Windows. |
Right, my comment was about the message. We could in theory say "Symbolic links are not supported on this file system." or just "Could not create symbolic link." instead of getting the OS message. My care level is low though. |
|
"CreateSymbolicLink -> IOException Incorrect function" I am aware of this and am forced to depend on it. Changing the error message is a good idea but I'm catching it by |
|
@joshudson any interest in offering a PR for that message? Note of course that checking HResult makes your code Windows only. Unless and until this old issue progresses. |
Nope! I use magic readonly variables. https:/joshudson/Emet/blob/master/README.md Anyway I'm not going to make a PR because I don't want to deal with the localization code. |
|
@danmoseley is this one still open? |
|
@Danyy427 sure, you're welcome to have it. Suggestion: start with a small PR to make sure you're on the right track. |
|
@danmoseley I created a FAT32 volume on my windows machine and moved TEMP and TMP variables. The tests did pass with a bunch of skips. Weren't they supposed to fail? |
|
@Danyy427 something is wrong: for some reason the test project is not using your FAT32 drive |
|
@adamsitnik would I have to do anything besides changing TEMP and TMP variables (and restarting my PC) for the project to start using the new TEMP location specifically? Should I perhaps rebuild the project for example? |
|
Hmm I can see that most the tests are using which uses which performs the which is documented to use the environment variables you have mentioned:
restarting the PC should not be required, all you need to do is to start a new command prompt could you print the TMP env var? echo %TMP% |
|
@adamsitnik oh yeah, I was supposed to change TEMP and TMP for the user profile. I changed the system variables. That fixed it, thank you. |
|
User profile vs system shouldn’t matter. You may have just forgotten to open a fresh command prompt after making the change. |
Some tests in System.IO.FileSystem are conditionalized on being run on a FAT32 volume (specifically, that temp is on FAT32 -- location of the repo or artifacts folder is not relevant here)
runtime/src/libraries/System.IO.FileSystem/tests/FileStream/ctor_options.Windows.cs
Line 61 in 7db092a
So I'd expect this library to pass when temp is on FAT32. We certainly should test on FAT32 since we support using .NET against FAT32 volumes. I changed TEMP and TMP env variables to a FAT32 volume and ran this test library. Unsurprisingly because this hasn't been done in a long time and there are many failures, below are the various failure modes. Presumably we want to fix this so that we have some way to confirm that our IO APIs work fine on FAT32. (In an ideal world, all our tests that use the file system would be known to pass on FAT32, but minimally our IO tests would)
The failures below are
failures
On Unix one can make an in-memory FAT32 volume to test on like this, but I don't know how to do that on Windows.
The text was updated successfully, but these errors were encountered: