Tests on Linux are filesystem-dependent about dust HOT 5 CLOSED

That sounds like a good idea.

I was not aware that this would be a problem but it makes sense. I'll look at copying everything to /tmp for the tests.

from dust.

An alternative would be to determine what file system we are looking at and then adjust the tests accordingly.

We could also run the tests as 'result == X or result == Y or result == Z' and let any of them pass.

This needs some thought and it should be resolved.

Windows users were also reporting inconsistent numbers on their machines.

from dust.

I think adding specific per-filesystem test results is doomed to failure from the outset — there are simply too many choices, where do you draw the line as to adding a new filesystem? Whose job is it to then update all those filesystem-specific results? What if one filesystem's success matches also another filesystem's failure?

We already have #[cfg(target_os)] for Mac and Linux, I think adding one more for Windows and then requiring that the tests be run on APFS, tmpfs, or NTFS respectively isn't an unreasonable technical burden on either side.

from dust.

I think adding specific per-filesystem test results is doomed to failure from the outset — there are simply too many choices,

Agreed.

I am also considering changing the tests so they only look at the file names and ignore the files sizes. However I don't like this idea as we would then loose the ability to test a 'complete' output.

I'm doing a refactor at the minute and I'm keeping testing in mind.

I think your idea of using the /tmp directory may be the best option if the CI runners allow it.

from dust.

1f120de

This commit copies the tests files to the /tmp/ directory this should fix it.

from dust.