This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Introduce the 'usertemp' filesystem type


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: pgp5R6AxOls6i.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]