bootandy/archived-dust
1
0
Fork 0
mirror of https://github.com/bootandy/dust.git synced 2026-06-08 11:29:05 +03:00
Code Issues 21 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #56] Commit bdc3d40 breaks windows builds #22

New Issue
Closed
opened 2026-06-08 11:25:20 +03:00 by zhus · 11 comments
zhus commented 2026-06-08 11:25:20 +03:00
Owner
Copy Link
Copy Source

Originally created by @rivy on GitHub (Jan 20, 2020).
Original GitHub issue: https://github.com/bootandy/dust/issues/56

v0.4.3 builds and installs, but the changes in bdc3d40 break windows compilation (even when using 'nightly').

I just noticed when updating to the most recent version (v0.4.4).

I've looked through the code and it looks like using the unstable metadata.file_index() and metadata.volume_serial_number() as well as missing get_filesystem() are the culprits.

Here's the build output:

C:>cargo +nightly build
   Compiling du-dust v0.4.3 (C:\Users\Roy\OneDrive\Projects\rust\rs.dust)
error[E0425]: cannot find function `get_filesystem` in this scope
   --> src\utils\mod.rs:102:26
    |
102 |         if let Some(a) = get_filesystem(file_name) {
    |                          ^^^^^^^^^^^^^^ not found in this scope

error[E0658]: use of unstable library feature 'windows_by_handle'
  --> src\utils\platform.rs:28:52
   |
28 |         let windows_equivalent_of_inode = Some((md.file_index(), md.volume_serial_number()));
   |                                                    ^^^^^^^^^^
   |
   = note: for more information, see https://github.com/rust-lang/rust/issues/63010
   = help: add `#![feature(windows_by_handle)]` to the crate attributes to enable

error[E0658]: use of unstable library feature 'windows_by_handle'
  --> src\utils\platform.rs:28:69
   |
28 |         let windows_equivalent_of_inode = Some((md.file_index(), md.volume_serial_number()));
   |                                                                     ^^^^^^^^^^^^^^^^^^^^
   |
   = note: for more information, see https://github.com/rust-lang/rust/issues/63010
   = help: add `#![feature(windows_by_handle)]` to the crate attributes to enable

error[E0308]: mismatched types
  --> src\utils\platform.rs:27:5
   |
25 |   pub fn get_metadata(d: &DirEntry, use_apparent_size: bool) -> Option<(u64, Option<(u64, u64)>)> {
   |                                                                 --------------------------------- expected `std::option::Option<(u64, std::option::Option<(u64, u64)>)>` because of return type
26 |       use std::os::windows::fs::MetadataExt;
27 | /     d.metadata.as_ref().unwrap().as_ref().ok().map(|md| {
28 | |         let windows_equivalent_of_inode = Some((md.file_index(), md.volume_serial_number()));
29 | |         (md.file_size(), windows_equivalent_of_inode)
30 | |     })
   | |______^ expected `u64`, found enum `std::option::Option`
   |
   = note: expected enum `std::option::Option<(_, std::option::Option<(u64, u64)>)>`
              found enum `std::option::Option<(_, std::option::Option<(std::option::Option<u64>, std::option::Option<u32>)>)>`

error[E0658]: use of unstable library feature 'windows_by_handle'
  --> src\utils\platform.rs:54:19
   |
54 |     Some(metadata.volume_serial_number())
   |                   ^^^^^^^^^^^^^^^^^^^^
   |
   = note: for more information, see https://github.com/rust-lang/rust/issues/63010
   = help: add `#![feature(windows_by_handle)]` to the crate attributes to enable

error[E0308]: mismatched types
  --> src\utils\platform.rs:54:10
   |
54 |     Some(metadata.volume_serial_number())
   |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u64`, found enum `std::option::Option`
   |
   = note: expected type `u64`
              found enum `std::option::Option<u32>`

error: aborting due to 6 previous errors

Some errors have detailed explanations: E0308, E0425, E0658.
For more information about an error, try `rustc --explain E0308`.
error: could not compile `du-dust`.

To learn more, run the command again with --verbose.
Originally created by @rivy on GitHub (Jan 20, 2020). Original GitHub issue: https://github.com/bootandy/dust/issues/56 v0.4.3 builds and installs, but the changes in bdc3d40 break windows compilation (even when using 'nightly'). I just noticed when updating to the most recent version (v0.4.4). I've looked through the code and it looks like using the unstable `metadata.file_index()` and `metadata.volume_serial_number()` as well as missing `get_filesystem()` are the culprits. Here's the build output: ``` shell C:>cargo +nightly build Compiling du-dust v0.4.3 (C:\Users\Roy\OneDrive\Projects\rust\rs.dust) error[E0425]: cannot find function `get_filesystem` in this scope --> src\utils\mod.rs:102:26 | 102 | if let Some(a) = get_filesystem(file_name) { | ^^^^^^^^^^^^^^ not found in this scope error[E0658]: use of unstable library feature 'windows_by_handle' --> src\utils\platform.rs:28:52 | 28 | let windows_equivalent_of_inode = Some((md.file_index(), md.volume_serial_number())); | ^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/63010 = help: add `#![feature(windows_by_handle)]` to the crate attributes to enable error[E0658]: use of unstable library feature 'windows_by_handle' --> src\utils\platform.rs:28:69 | 28 | let windows_equivalent_of_inode = Some((md.file_index(), md.volume_serial_number())); | ^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/63010 = help: add `#![feature(windows_by_handle)]` to the crate attributes to enable error[E0308]: mismatched types --> src\utils\platform.rs:27:5 | 25 | pub fn get_metadata(d: &DirEntry, use_apparent_size: bool) -> Option<(u64, Option<(u64, u64)>)> { | --------------------------------- expected `std::option::Option<(u64, std::option::Option<(u64, u64)>)>` because of return type 26 | use std::os::windows::fs::MetadataExt; 27 | / d.metadata.as_ref().unwrap().as_ref().ok().map(|md| { 28 | | let windows_equivalent_of_inode = Some((md.file_index(), md.volume_serial_number())); 29 | | (md.file_size(), windows_equivalent_of_inode) 30 | | }) | |______^ expected `u64`, found enum `std::option::Option` | = note: expected enum `std::option::Option<(_, std::option::Option<(u64, u64)>)>` found enum `std::option::Option<(_, std::option::Option<(std::option::Option<u64>, std::option::Option<u32>)>)>` error[E0658]: use of unstable library feature 'windows_by_handle' --> src\utils\platform.rs:54:19 | 54 | Some(metadata.volume_serial_number()) | ^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/63010 = help: add `#![feature(windows_by_handle)]` to the crate attributes to enable error[E0308]: mismatched types --> src\utils\platform.rs:54:10 | 54 | Some(metadata.volume_serial_number()) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u64`, found enum `std::option::Option` | = note: expected type `u64` found enum `std::option::Option<u32>` error: aborting due to 6 previous errors Some errors have detailed explanations: E0308, E0425, E0658. For more information about an error, try `rustc --explain E0308`. error: could not compile `du-dust`. To learn more, run the command again with --verbose. ```
zhus closed this issue 2026-06-08 11:25:20 +03:00
zhus commented 2026-06-08 11:25:20 +03:00
Author
Owner
Copy Link
Copy Source

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

Thanks.

I was trying to be helpful for a future windows version but I hadn't tested it.

I'll remove the windows specific stuff or add a windows compile step on CI

<!-- gh-comment-id:576459021 --> @bootandy commented on GitHub (Jan 21, 2020): Thanks. I was trying to be helpful for a future windows version but I hadn't tested it. I'll remove the windows specific stuff or add a windows compile step on CI
zhus commented 2026-06-08 11:25:20 +03:00
Author
Owner
Copy Link
Copy Source

@rivy commented on GitHub (Jan 21, 2020):

Thanks for the quick response.

I was attempting to create a PR to fix it, at least for nightly, but I'm lost in the pragma weeds. I can't create a working build despite the "helpful" cargo/rustc error messages about using #![feature(windows_by_handle)].

And I haven't seen or created a Travis-CI windows build recipe. I have, however, created both AppVeyor (see uutils/coreutils) and a GitHub-Actions CIs (linux, macos, and windows; see Peltoche/lsd), if you're interested in seeing some working code.

I'd be happy to donate some time and submit a PR along those lines if helpful.

And just FYI... I think that the GitHub-Actions CI would be better; it's inclusive of all the major OSs and is much faster than Travis and/or AppVeyor. Notably, the "x86_64-pc-windows-gnu" target is problematic right now (though hopefully a fix is in the works [see GH:rust-lang/rust#67429]), but "x86_64-pc-windows-msvc" works fine.

<!-- gh-comment-id:576769407 --> @rivy commented on GitHub (Jan 21, 2020): Thanks for the quick response. I was attempting to create a PR to fix it, at least for nightly, but I'm lost in the pragma weeds. I can't create a working build despite the "helpful" `cargo`/`rustc` error messages about using `#![feature(windows_by_handle)]`. And I haven't seen or created a Travis-CI windows build recipe. I have, however, created both AppVeyor (see [uutils/coreutils](https://github.com/uutils/coreutils/blob/91899b34b96da40797846f343f399ca420777c6a/.appveyor.yml)) and a GitHub-Actions CIs (linux, macos, and windows; see [Peltoche/lsd](https://github.com/Peltoche/lsd/blob/13fa06886858561dfbdd4c04b6867c2bd2e3d7f5/.github/workflows/CICD.yml)), if you're interested in seeing some working code. I'd be happy to donate some time and submit a PR along those lines if helpful. And just FYI... I think that the GitHub-Actions CI would be better; it's inclusive of all the major OSs and is much faster than Travis and/or AppVeyor. Notably, the "x86_64-pc-windows-gnu" target is problematic right now (though hopefully a fix is in the works [see [GH:rust-lang/rust#67429](https://github.com/rust-lang/rust/pull/67429)]), but "x86_64-pc-windows-msvc" works fine.
zhus commented 2026-06-08 11:25:20 +03:00
Author
Owner
Copy Link
Copy Source

@lespea commented on GitHub (Jan 21, 2020):

@rivy do you want to double check my pr to make sure it works for you (worked on my machine)

<!-- gh-comment-id:576818526 --> @lespea commented on GitHub (Jan 21, 2020): @rivy do you want to double check my pr to make sure it works for you (worked on my machine)
zhus commented 2026-06-08 11:25:20 +03:00
Author
Owner
Copy Link
Copy Source

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

@lespea , sure ... done.
Build works but cargo test fails to compile.
I posted details on the PR thread.

<!-- gh-comment-id:576906407 --> @rivy commented on GitHub (Jan 22, 2020): @lespea , sure ... done. Build works but `cargo test` fails to compile. I posted details on the PR thread.
zhus commented 2026-06-08 11:25:20 +03:00
Author
Owner
Copy Link
Copy Source

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

So to sum up, I've merged lespea's changes which should fix compiling on windows

The tests won't run on windows until someone adds this missing OS dependent functions in tests.rs - I can't do this as I don't have a windows box. If someone adds them I'll merge it.

If we are going to support windows from now then I'd like to see windows included as a CI build. I have no strong feelings about which CI to use (apart from the fact I don't like fiddling with CI much). If someone is happy modifying the .travis CI or converting it to another CI system to include the big 3: windows/mac/linux. Then that would be most welcome.

<!-- gh-comment-id:576921047 --> @bootandy commented on GitHub (Jan 22, 2020): So to sum up, I've merged lespea's changes which should fix compiling on windows The tests won't run on windows until someone adds this missing OS dependent functions in `tests.rs` - I can't do this as I don't have a windows box. If someone adds them I'll merge it. If we are going to support windows from now then I'd like to see windows included as a CI build. I have no strong feelings about which CI to use (apart from the fact I don't like fiddling with CI much). If someone is happy modifying the .travis CI or converting it to another CI system to include the big 3: windows/mac/linux. Then that would be most welcome.
zhus commented 2026-06-08 11:25:20 +03:00
Author
Owner
Copy Link
Copy Source

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

Alright, I've got a semi-working branch with GHA-CI.

I'll proceed to stamp out some of the windows testing bugs and post a PR.

<!-- gh-comment-id:576932298 --> @rivy commented on GitHub (Jan 22, 2020): Alright, I've got a semi-working branch with GHA-CI. I'll proceed to stamp out some of the windows testing bugs and post a PR.
zhus commented 2026-06-08 11:25:20 +03:00
Author
Owner
Copy Link
Copy Source

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

@bootandy , initial PR submitted.

It'll need some review and a bit more thought/investigation before merge.

<!-- gh-comment-id:577291515 --> @rivy commented on GitHub (Jan 22, 2020): @bootandy , initial [PR](https://github.com/bootandy/dust/pull/62) submitted. It'll need some review and a bit more thought/investigation before merge.
zhus commented 2026-06-08 11:25:21 +03:00
Author
Owner
Copy Link
Copy Source

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

@lespea , if you get a chance to test 834efe7 , I'd appreciate it. It includes some windows tests which pas on my local machine, but vary by one byte in size on the CI host. I'm curious what results you get.

<!-- gh-comment-id:577311815 --> @rivy commented on GitHub (Jan 22, 2020): @lespea , if you get a chance to test 834efe7 , I'd appreciate it. It includes some windows tests which pas on my local machine, but vary by one byte in size on the CI host. I'm curious what results you get.
zhus commented 2026-06-08 11:25:21 +03:00
Author
Owner
Copy Link
Copy Source

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

I can test tonight but I won't be home for a while (probably at least another 8 hours) :/. I'l post results when I get them!

<!-- gh-comment-id:577324382 --> @lespea commented on GitHub (Jan 22, 2020): I can test tonight but I won't be home for a while (probably at least another 8 hours) :/. I'l post results when I get them!
zhus commented 2026-06-08 11:25:21 +03:00
Author
Owner
Copy Link
Copy Source

@lespea commented on GitHub (Jan 23, 2020):

Testing #62 passes but I get the off-by-one error for 834efe7

<!-- gh-comment-id:577490916 --> @lespea commented on GitHub (Jan 23, 2020): Testing #62 passes but I get the off-by-one error for 834efe7
zhus commented 2026-06-08 11:25:21 +03:00
Author
Owner
Copy Link
Copy Source

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

The above PR now builds windows versions. Thanks @rivy

<!-- gh-comment-id:581614205 --> @bootandy commented on GitHub (Feb 3, 2020): The above PR now builds windows versions. Thanks @rivy
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
good first issue
help wanted
pull-request
Mirrored from GitHub Pull Request
 windows help wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
zhus (Sergey Zhukov)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bootandy/archived-dust#22
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?