Fails to set Modified Time on FAT32 and exFAT

[khionu]

I have been debugging an issue with Cargo validating the crate as a tarball and I had traced it to being invalid arguments being sent to Windows. I was recommended to try moving the project to my main drive on a whim, and surprisingly that fixed my issue. After some testing, I found that, of FAT32, exFAT, and NTFS, only NTFS worked while on the NT Kernel.

[memoryruins]

Below is the error from cargo package with debug rustlog on linux with an exFAT usb drive.

DEBUG 2018-10-21T22:04:11Z: cargo::core::workspace: find_root - trying /home/michael/lexar/Cargo.toml
DEBUG 2018-10-21T22:04:11Z: cargo::core::workspace: find_root - trying /home/michael/Cargo.toml
DEBUG 2018-10-21T22:04:11Z: cargo::core::workspace: find_root - trying /home/Cargo.toml
DEBUG 2018-10-21T22:04:11Z: cargo::core::workspace: find_root - trying /Cargo.toml
DEBUG 2018-10-21T22:04:11Z: cargo::core::workspace: find_members - only me as a member
DEBUG 2018-10-21T22:04:11Z: cargo::ops::resolve: attempting to prefer evac_test v0.1.0 (/home/michael/lexar/evac_test)
DEBUG 2018-10-21T22:04:11Z: cargo::core::registry: load/missing  /home/michael/lexar/evac_test
DEBUG 2018-10-21T22:04:11Z: cargo::core::registry: loading source /home/michael/lexar/evac_test
DEBUG 2018-10-21T22:04:11Z: cargo::sources::config: loading: /home/michael/lexar/evac_test
DEBUG 2018-10-21T22:04:11Z: cargo::core::resolver: initial activation: evac_test v0.1.0 (/home/michael/lexar/evac_test)
warning: manifest has no description, license, license-file, documentation, homepage or repository.
See http://doc.crates.io/manifest.html#package-metadata for more info.
DEBUG 2018-10-21T22:04:11Z: cargo::ops::cargo_package: found a git repo at "/home/michael/lexar/evac_test/"
DEBUG 2018-10-21T22:04:11Z: cargo::ops::cargo_package: found (git) Cargo.toml at "Cargo.toml" in workdir "/home/michael/lexar/evac_test/"
   Packaging evac_test v0.1.0 (/home/michael/lexar/evac_test)
   Verifying evac_test v0.1.0 (/home/michael/lexar/evac_test)
DEBUG 2018-10-21T22:04:11Z: cargo: exit_with_error; err=CliError { error: Some(Custom { kind: PermissionDenied, error: TarError { desc: "failed to unpack `/home/michael/lexar/evac_test/target/package/evac_test-0.1.0/Cargo.toml.orig`", io: Custom { kind: PermissionDenied, error: TarError { desc: "failed to set mtime for `/home/michael/lexar/evac_test/target/package/evac_test-0.1.0/Cargo.toml.orig`", io: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" } } } } }

failed to verify package tarball), unknown: false, exit_code: 101 }
error: failed to verify package tarball

Caused by:
  failed to unpack `/home/michael/lexar/evac_test/target/package/evac_test-0.1.0/Cargo.toml.orig`

I was unable to test a FAT32 drive at this time

cargo: 1.31.0-nightly (09ce4b519 2018-10-16)
OS: Arch Linux x86_64
Kernel: 4.14.76-1-lts

[alexcrichton]

Thanks for the report! I'm not sure that we want to fix this in this crate though because the error here is legitimate. The error happens in tar and is propagated here, but specifically in Cargo we're ok ignoring these sorts of errors. Perhaps a feature could be added to tar to optionally ignore the errors an then Cargo could turn that on by default?

[khionu]

error here is legitimate.

Legitimate? How is it legitimate in such a way where it shouldn't be compensated for? Is this crate not responsible for the arguments that are being called invalid? I'm not used to working with components this low-level, and while I do see that this is something that should be handled out of the scope of this crate, the fact that there is different behavior for FAT-derived FS's and NTFS/extN FS's is an issue I would imagine needs to be handled somewhere...

Assuming you're correct in your assessment, I would agree that that's the best course of action.

[alexcrichton]

Er sorry by legitimate it looks like the filesystem simply doesn't support changing mtimes. I don't think the arguments to the syscall are invalid, it's just not possible to do this operation.

[khionu]

Ahh... then, yes, I would agree with your course of action.

I'll open the issues where appropriate.