git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Konrad Bucheli (PSI)" <konrad.bucheli@psi.ch>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	 git@vger.kernel.org, ps@pks.im
Subject: Re: chmod failure on GVFS mounted CIFS share
Date: Fri, 20 Dec 2024 07:44:17 -0800	[thread overview]
Message-ID: <xmqq8qsafjfy.fsf@gitster.g> (raw)
In-Reply-To: <c287fbd7-eb08-45f1-953b-5afd4fe41f9f@psi.ch> (Konrad Bucheli's message of "Fri, 20 Dec 2024 15:42:36 +0100")

"Konrad Bucheli (PSI)" <konrad.bucheli@psi.ch> writes:

> I have another idea: there is no need for a chmod if both the config
> file and the lock file already have he same mode. Which is the case if
> the filesystem has no proper chmod support.

And for majority of people who have working chmod(), would it mean
one extra and unnecessary system call?

Instead, how about doing the chmod() first, like we have always done,
but after seeing it fail, check with lstat() to see if the modes are
already in the desired state and refrain from complaining if that is
the case?  That way, we'll incur extra overhead only in the error
code path, which is the usual pattern we would prefer to do things.

So instead of removing this part, ...

> -		if (chmod(get_lock_file_path(&lock), st.st_mode & 07777) < 0) {
> -			error_errno(_("chmod on %s failed"), get_lock_file_path(&lock));

... you'd do an extra lstat() on the lock file (so you can move the
st_lock inside this block, narrowing its scope) before calling
error_errno(), and only after finding out that st_lock cannot
somehow be obtained or the resulting mode is different, you call
error_errno() and arrange an error to be returned, all inside the
if(){} block of the original.

Wouldn't it work even better, I wonder?

Thanks.

> +		if (stat(get_lock_file_path(&lock), &st_lock) == -1) {
> +			error_errno(_("stat on %s failed"), get_lock_file_path(&lock));
>  			ret = CONFIG_NO_WRITE;
>  			goto out_free;
>  		}
>  
> +		if ((st.st_mode & 07777) != (st_lock.st_mode & 07777)) {
> +			if (chmod(get_lock_file_path(&lock), st.st_mode & 07777) < 0) {
> +				error_errno(_("chmod on %s failed"), get_lock_file_path(&lock));
> +				ret = CONFIG_NO_WRITE;
> +				goto out_free;
> +			}
> +		}
> +
>  		if (store.seen_nr == 0) {
>  			if (!store.seen_alloc) {
>  				/* Did not see key nor section */


  reply	other threads:[~2024-12-20 15:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12  9:14 chmod failure on GVFS mounted CIFS share Konrad Bucheli (PSI)
2024-12-13  3:41 ` brian m. carlson
2024-12-13 10:32   ` Konrad Bucheli (PSI)
2024-12-15 22:30     ` brian m. carlson
2024-12-20 14:42       ` Konrad Bucheli (PSI)
2024-12-20 15:44         ` Junio C Hamano [this message]
2024-12-20 15:50           ` Konrad Bucheli (PSI)
2025-01-10 12:05             ` Konrad Bucheli (PSI)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq8qsafjfy.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=konrad.bucheli@psi.ch \
    --cc=ps@pks.im \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).