Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: zola serve no longer includes output directory content because of path canonicalization mismatch #2398

Merged
merged 1 commit into from
Jan 7, 2024

Conversation

stanistan
Copy link
Contributor

This fixes a bug introduced in #2258

The issue arose when output_path was relative. The request being served would be canonicalized and this would be a string. So, for example, if you were serving content from public the code right after the canonicalization checking if
root.starts_with(original_root) would always return false since an absolute path, /some/path/to/content would never start with a string like public.


Sanity check:

  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Code changes

(Delete or ignore this section for documentation changes)

  • Are you doing the PR on the next branch?

If the change is a new feature or adding to/changing an existing one:

  • Have you created/updated the relevant documentation page(s)?

@stanistan stanistan force-pushed the serve-content-root-bug branch from 11b265b to ac4c54d Compare January 2, 2024 16:54
This fixes a bug introduced in getzola#2258

The issue arose when `output_path` was relative. The request being
served would be canonicalized and this would be a string. So, for
example, if you were serving content from `public` the code
[right after](https://github.com/getzola/zola/blob/38199c125501e9ff0e700e96adaca72cc3f25d2b/src/cmd/serve.rs#L144-L147)
the canonicalization checking if
`root.starts_with(original_root)` would always return `false` since
an absolute path, `/some/path/to/content` would never start with a
string like `public`.
@stanistan stanistan force-pushed the serve-content-root-bug branch from ac4c54d to df19f5e Compare January 2, 2024 16:56
@Keats Keats merged commit 42ea1b4 into getzola:next Jan 7, 2024
5 checks passed
@Keats
Copy link
Collaborator

Keats commented Jan 7, 2024

Thanks!

@wold5
Copy link
Contributor

wold5 commented Feb 21, 2024

The Windows build of next on my machine, crashes on the line of this patch:

let static_root = std::fs::canonicalize(&output_path).unwrap();

thread 'main' panicked at src\cmd\serve.rs:470:59:
called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: Uncategorized, message: "Onjuiste functie." }

The last bit meaning "Incorrect function"

This occurs with both the test_site and my own.
A first suggestion was this being due to the older Rust 1.70, but 1.76 didn't help (after removing the old install and rebooting).

  • Rust 1.76
  • Windows 11 23H2 22631.3155
  • Zola Next branch, 21 feb '24, latest commit being 42fc576

If you need more info, let me know. Else tomorrow I'll explore some more.

PS C:\Users\-\workbench\syncoda> $Env:RUST_BACKTRACE = "full"
PS C:\Users\-\workbench\syncoda> R:\debug\zola.exe serve --force -o R:\testzola4\
Building site...
Checking all internal links with anchors.
> Successfully checked 9 internal link(s) with anchors.
-> Creating 33 pages (0 orphan) and 12 sections
Done in 25.8s.

thread 'main' panicked at src\cmd\serve.rs:470:59:
called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: Uncategorized, message: "Onjuiste functie." }
stack backtrace:
   0:     0x7ff7915f8e62 - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\sys_common\backtrace.rs:44
   1:     0x7ff7916209dd - core::fmt::rt::Argument::fmt
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\core\src\fmt\rt.rs:142
   2:     0x7ff7916209dd - core::fmt::write
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\core\src\fmt\mod.rs:1120
   3:     0x7ff7915f39f1 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\io\mod.rs:1810
   4:     0x7ff7915f8c8a - std::sys_common::backtrace::_print
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\sys_common\backtrace.rs:47
   5:     0x7ff7915f8c8a - std::sys_common::backtrace::print
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\sys_common\backtrace.rs:34
   6:     0x7ff7915fb139 - std::panicking::default_hook::closure$1
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:272
   7:     0x7ff7915fadf5 - std::panicking::default_hook
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:292
   8:     0x7ff7915fb664 - std::panicking::rust_panic_with_hook
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:779
   9:     0x7ff7915fb539 - std::panicking::begin_panic_handler::closure$0
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:657
  10:     0x7ff7915f9769 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0,never$>
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\sys_common\backtrace.rs:171
  11:     0x7ff7915fb202 - std::panicking::begin_panic_handler
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:645
  12:     0x7ff791717e97 - core::panicking::panic_fmt
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\core\src\panicking.rs:72
  13:     0x7ff7917184d3 - core::result::unwrap_failed
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\core\src\result.rs:1649
  14:     0x7ff78f998e53 - core::result::Result<T,E>::unwrap::h3592380a73273158
  15:     0x7ff78f94a6ec - zola::cmd::serve::serve::h066009d342b471d8
  16:     0x7ff78f9572a3 - std::sync::once_lock::OnceLock<T>::get_or_init::hc2a0b08e6a14b5dc
  17:     0x7ff78f93cb96 - core::ops::function::FnOnce::call_once::hba30155141b619c6
  18:     0x7ff78f971219 - std::sys_common::backtrace::__rust_begin_short_backtrace::h128977495901bf94
  19:     0x7ff78f95a0ac - std::rt::lang_start::{{closure}}::he37f2dfb38392a88
  20:     0x7ff7915ec312 - std::rt::lang_start_internal::closure$2
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\rt.rs:148
  21:     0x7ff7915ec312 - std::panicking::try::do_call
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:552
  22:     0x7ff7915ec312 - std::panicking::try
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panicking.rs:516
  23:     0x7ff7915ec312 - std::panic::catch_unwind
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\panic.rs:142
  24:     0x7ff7915ec312 - std::rt::lang_start_internal
                               at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library\std\src\rt.rs:148
  25:     0x7ff78f95a087 - std::rt::lang_start::h2332faeb96437655
  26:     0x7ff78f957e79 - main
  27:     0x7ff7917159bc - invoke_main
                               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  28:     0x7ff7917159bc - __scrt_common_main_seh
                               at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  29:     0x7ffcfcbd257d - BaseThreadInitThunk
  30:     0x7ffcfdfcaa58 - RtlUserThreadStart

@stanistan
Copy link
Contributor Author

Not sure if this is related (I don't have access to test on a windows machine), but I found this one other issue about where canonicalize might not be supported on all kinds of drives.

nushell/nushell#9871 (comment)

veluca93 pushed a commit to veluca93/zola that referenced this pull request May 14, 2024
This fixes a bug introduced in getzola#2258

The issue arose when `output_path` was relative. The request being
served would be canonicalized and this would be a string. So, for
example, if you were serving content from `public` the code
[right after](https://github.com/getzola/zola/blob/38199c125501e9ff0e700e96adaca72cc3f25d2b/src/cmd/serve.rs#L144-L147)
the canonicalization checking if
`root.starts_with(original_root)` would always return `false` since
an absolute path, `/some/path/to/content` would never start with a
string like `public`.
Keats pushed a commit that referenced this pull request Jun 20, 2024
This fixes a bug introduced in #2258

The issue arose when `output_path` was relative. The request being
served would be canonicalized and this would be a string. So, for
example, if you were serving content from `public` the code
[right after](https://github.com/getzola/zola/blob/38199c125501e9ff0e700e96adaca72cc3f25d2b/src/cmd/serve.rs#L144-L147)
the canonicalization checking if
`root.starts_with(original_root)` would always return `false` since
an absolute path, `/some/path/to/content` would never start with a
string like `public`.
berdandy pushed a commit to berdandy/azola that referenced this pull request Sep 17, 2024
This fixes a bug introduced in getzola#2258

The issue arose when `output_path` was relative. The request being
served would be canonicalized and this would be a string. So, for
example, if you were serving content from `public` the code
[right after](https://github.com/getzola/zola/blob/38199c125501e9ff0e700e96adaca72cc3f25d2b/src/cmd/serve.rs#L144-L147)
the canonicalization checking if
`root.starts_with(original_root)` would always return `false` since
an absolute path, `/some/path/to/content` would never start with a
string like `public`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants