From nobody Sat Sep 4 08:28:38 2021 X-Original-To: chromium@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 23F1F17A71E1 for ; Sat, 4 Sep 2021 08:28:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H1nqq0GsVz4Zx8 for ; Sat, 4 Sep 2021 08:28:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D9F49149A0 for ; Sat, 4 Sep 2021 08:28:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 1848ScFv031908 for ; Sat, 4 Sep 2021 08:28:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 1848Sckr031907 for chromium@FreeBSD.org; Sat, 4 Sep 2021 08:28:38 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: chromium@FreeBSD.org Subject: [Bug 258232] www/chromium not downloading but writing empty images.crdownload files Date: Sat, 04 Sep 2021 08:28:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ice@extreme.hu X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: chromium@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: FreeBSD-specific Chromium issues List-Archive: https://lists.freebsd.org/archives/freebsd-chromium List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-chromium@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258232 ice@extreme.hu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ice@extreme.hu --- Comment #8 from ice@extreme.hu --- I am hit by a similar issue, but the cause is apparently very different. 91.0.4472.164 was fine, the problems started with 92-something, as far as I remember. One might call my setup a bit awkward: /tmp is a separate ZFS dataset, and this is what I have my 'download direct= ory' set to in Chromium /usr/home is another ZFS dataset which is where the bulk of my home lives however ~/.local is a symlink to a directory in yet another ZFS data set This setup stopped working in about Chromium 92. If I set my 'download directory' to ~/.local/, it starts working again. It looks like Chromium wants to create a temp file in ~/.local/: 14121 chrome NAMI "/home/ice/.local/share/.org.chromium.Chromium.A1I94j" and then a bit later 14121 chrome NAMI "/home/ice/.local/share/.org.chromium.Chromium.A1I94j" 14121 chrome NAMI "/tmp/.crdownload" 14121 chrome CALL write(0x1d,0x7fffffffcd3f,0x1) 14121 chrome RET rename -1 errno 18 Cross-device link This made my try pointing Chromium to ~/.local/ as the download directory, = and this works (as far as Chromium is now able to produce an actual file). To be honest this looks a bit odd - if there is a specific directory to download files into, and Chromium is using rename to get to the final file = name from the temp file name, why is the temp file being created in a random directory very distinctly not the same as the download directory? That said, this all may be a red herring - the only thing certain is with t= his filesystem setup and download dir set to /tmp, Chromium isn't downloading things :) --=20 You are receiving this mail because: You are the assignee for the bug.=