From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH] Introduce the 'usertemp' filesystem type
Date: Wed, 21 Oct 2015 18:23:00 -0000 [thread overview]
Message-ID: <20151021182346.GE17374@calimero.vinschen.de> (raw)
In-Reply-To: <alpine.DEB.1.00.1510201251140.31610@s15462909.onlinehome-server.info>
[-- Attachment #1: Type: text/plain, Size: 4307 bytes --]
Hi Johannes,
On Oct 20 13:47, Johannes Schindelin wrote:
> On Tue, 20 Oct 2015, Corinna Vinschen wrote:
> > On Sep 16 09:35, Johannes Schindelin wrote:
> > > * mount.cc (mount_info::from_fstab_line): support mounting the
> > > current user's temp folder as /tmp/. This is particularly
> > > useful a feature when Cygwin's own files are write-protected.
> > >
> > > * pathnames.xml: document the new usertemp file system type
>
> BTW I thought this would be the preferred form of the ChangeLog entry: as
> part of the commit message. At least that is how I interpreted this part:
>
> ChangeLogs should not be sent as "diffs". Just send the complete
> ChangeLog entry, which is ideally part of the output of
> `git format-patch' anyway.
>
> of https://cygwin.com/contrib.html
Duh, I missed that from your OP. Somehow I started reading with
"Detailed explanation:". Sorry about that.
> > > By specifying
> > >
> > > none /tmp usertemp binary,posix=0 0 0
> > >
> > > in /etc/fstab, the /tmp/ directory gets auto-mounted to the directory
> > > specified by the %TEMP% variable.
> >
> > In theory you could also utilize /etc/fstab.d/$USER, without the need to
> > implement a usertemp mount type.
>
> This is unfortunately not possible. The use case that triggered this patch
> is Git for Windows (which does not use Cygwin directly, but the MSys2
> runtime which is derived from Cygwin).
Editorial note:
It's a bit hard to understand why we need Git for Windows while there's
a full fledged git available as part of the Cygwin distro. It's also
very frustrating that a Git for Windows standalone tool gets a lot of
press coverage while nobody seems to care that Git for Windows under
Cygwin exists for ages. Sigh.
> Indeed. In Git for Windows' case, this is actually a feature. That way,
> different users' files are encapsulated from each other.
> [...]
> As I said, in a multi-user setting, or even worse: in a portable
> application, this is simply not possible other than via the strategy
> implemented by this patch.
Here's a question. If it's really only about git, why do you need
to redirect /tmp, rather than having git use $TMP directly? That would
be much less intrusive than having to change the underlying POSIX
layer, isn't it?
> > - The ChangeLog entry is missing.
>
> See above. Do you want me to include the diff to winsup/cygwin/ChangeLog?
No, my bad, sorry.
> [...]
> > > + char mb_tmp[len = sys_wcstombs (NULL, 0, tmp)];
> >
> > - len = sys_wcstombs() + 1
>
> Whoops. I always get that wrong.
>
> But... actually... Did you know that `sys_wcstombs()` returns something
> different than advertised? The documentation says:
>
> - dst == NULL; len is ignored, the return value is the number
> of bytes required for the string without the trailing NUL, just
> like the return value of the wcstombs function.
>
> But when I call
>
> small_printf("len of 1: %d\n", sys_wcstombs(NULL, 0, L"1"));
>
> it prints "len of 1: 2", i.e. the number of bytes requires for the string
> *with* the trailing NUL, disagreeing with the comment in strfuncs.cc.
Drat. You're right. As usual I wonder why nobody ever noticed this.
As soon as the nwc parameter is larger than the number of non-0 wchars
in the source string, sys_cp_wcstombs returns the length including the
trailing NUL.
And looking through the Cygwin sources the usage is rather erratic,
sometimes with, sometimes without + 1 :(
> How do you want to proceed from here? Should I fix sys_wcstombs() when the
> fourth parameter is -1? Or is this not a fix, but I would rather break
> things?
No, this needs fixing, but it also would break things. I have to take
a stab at fixing this throughout Cygwin first.
> > - What about adding a mount flags to allow fillout_mntent to print out
> > the mount type? This isn't essential, I'm just wondering if there
> > might be a good reason to see the type in mount(1) output.
>
> You mean something like this?
>
> -- snip --
Yes, that's what I had in mind.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-10-21 18:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-16 7:35 Johannes Schindelin
2015-10-20 9:37 ` Corinna Vinschen
2015-10-20 11:47 ` Johannes Schindelin
2015-10-21 18:23 ` Corinna Vinschen [this message]
2015-10-22 12:45 ` Corinna Vinschen
2015-10-22 15:31 ` Johannes Schindelin
2015-12-01 14:02 ` [PATCH v2] " Johannes Schindelin
2015-12-01 14:12 ` Johannes Schindelin
2015-12-01 14:27 ` Corinna Vinschen
2015-12-01 14:50 ` Johannes Schindelin
2015-12-07 16:42 ` Corinna Vinschen
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=20151021182346.GE17374@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-patches@cygwin.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).