[GH-ISSUE #60] Tests on Linux are filesystem-dependent #27

New Issue

2026-06-08T11:25:21+03:00

zhus commented

2026-06-08 11:25:21 +03:00

Originally created by @Celti on GitHub (Jan 21, 2020).
Original GitHub issue: https://github.com/bootandy/dust/issues/60

When running cargo test while putting together #59, it came to my attention that tests on Linux are filesystem-dependent. test_dir2 is 12K on my XFS home filesystem or my tmpfs /tmp, whereas the tests expect 24K (perhaps from ext4?).

This should at minimum be documented, but I'd recommend copying the test files to /tmp and running them there, as the vast majority of Linux systems default to /tmp being a tmpfs.

Originally created by @Celti on GitHub (Jan 21, 2020). Original GitHub issue: https://github.com/bootandy/dust/issues/60 When running `cargo test` while putting together #59, it came to my attention that tests on Linux are filesystem-dependent. `test_dir2` is 12K on my XFS home filesystem or my tmpfs /tmp, whereas the tests expect 24K (perhaps from ext4?). This should at minimum be documented, but I'd recommend copying the test files to `/tmp` and running them there, as the vast majority of Linux systems default to `/tmp` being a tmpfs.

zhus closed this issue

2026-06-08 11:25:21 +03:00

zhus commented

2026-06-08 11:25:21 +03:00

@bootandy commented on GitHub (Jan 22, 2020):

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.

@bootandy commented on GitHub (Jan 22, 2020): 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.

zhus commented

2026-06-08 11:25:21 +03:00

@bootandy commented on GitHub (Feb 9, 2020):

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.

@bootandy commented on GitHub (Feb 9, 2020): 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.

zhus commented

2026-06-08 11:25:21 +03:00

@Celti commented on GitHub (Feb 10, 2020):

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.

@Celti commented on GitHub (Feb 10, 2020): 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.

zhus commented

2026-06-08 11:25:21 +03:00

@bootandy commented on GitHub (Feb 10, 2020):

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.

@bootandy commented on GitHub (Feb 10, 2020): >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.

zhus commented

2026-06-08 11:25:21 +03:00

@bootandy commented on GitHub (Mar 28, 2020):

https://github.com/bootandy/dust/commit/1f120de168fb2eae951bd81bd7566839834cbd16

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

@bootandy commented on GitHub (Mar 28, 2020): https://github.com/bootandy/dust/commit/1f120de168fb2eae951bd81bd7566839834cbd16 This commit copies the tests files to the /tmp/ directory this should fix it.

zhus referenced this issue

2026-06-08 11:26:32 +03:00

[PR #27] [MERGED] New2 #261

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bootandy/archived-dust#27