Why archive jwalk and move to dua-core?

[raldone01]

I am just curious why you didn't just bump a major version of jwalk with the rewrite to dua-core? I think that would be easier to discover (also for people updating). A rename is not very transparent. I just randomly checked the cargo page of jwalk to find out that you moved it.

Moving to a monorepo can make sense but that doesn't necessitate a name change.

Also the dua-core crate has no readme on crates.io and no examples.

[Byron]

What makes you think anything was renamed? jwalk is still what it was before, and the repository indicates this.
It's correct though that dua-core doesn't make it easy to be used in place of jwalk, but in the end, nobody needs to switch if jwalk works for them.
As dua-core serves dua, I think it's fine to not market it as general-purpose crate. From that point of view, it was a mistake to direct people to jwalk for a replacement, but then again, it's better than nothing.

[raldone01]

Actually I thought the switch to dua-core was quite easy and the API feels improved (like a jwalk 2.0 of sorts). Now I can walk multiple root dirs and even track them by index while traversing.

Too bad you feel that way about making it general purpose. You really saved me a lot of work writing something similar. Like 1M files in 13s with processing is super cool! Thanks.

Also thanks for addressing the issues.
Minor nit: Adding derive(Debug) for FileType works but I would have preferred some simple pretty printing (kind: u32, is not that helpful on macos).

[raldone01]

Another minor thing while moving from jwalk was that there doesn't seem to be a skip hidden files option. I think that is fine but while trying to write my own one I noticed that I dua_core::Entry doesn't have the metadata to identify hidden files on windows. If dua doesn't collect them that is fine but if it has that metadata it would be cool to expose it.

Called from descend:

#[cfg_attr(not(windows), expect(clippy::unnecessary_wraps))]
fn is_hidden(path: &Path) -> io::Result<bool> {
  // Unix convention: a leading dot in the file name (honored on all platforms)
  let is_dotfile = path
    .file_name()
    .and_then(|n| n.to_str())
    .is_some_and(|n| n.starts_with('.'));

  if is_dotfile {
    return Ok(true);
  }

  #[cfg(windows)]
  {
    use std::{fs, os::windows::fs::MetadataExt};
    const FILE_ATTRIBUTE_HIDDEN: u32 = 0x2;
    let meta = fs::metadata(path)?;
    Ok(meta.file_attributes() & FILE_ATTRIBUTE_HIDDEN != 0)
  }

  #[cfg(not(windows))]
  {
    Ok(false)
  }
}

[Byron]

Too bad you feel that way about making it general purpose.

If it works for you, I guess it's general-purpose enough already. It's using semver, so it's safe to rely on it while it works for you. dua-cli is done for me as well.

Minor nit: Adding derive(Debug) for FileType works but I would have preferred some simple pretty printing (kind: u32, is not that helpful on macos).

NP, contribute what you need.

If dua doesn't collect them that is fine but if it has that metadata it would be cool to expose it.

Hidden files are nothing that dua needs, so it's not included.

Maybe you can make the callbacks expose more of the metadata that already exists if it's not good enough, so you don't have to do extra calls. I'd be surprised if such a simple 'hidden' attribute on Windows wasn't already included. Again, contribute what you need, if it's already present, it should be fine to expose it.

[raldone01]

Cool. I think it should be simple enough to just plumb that through. Glad to know you accept prs.