From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-patches@cygwin.com
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] Introduce the 'usertemp' filesystem type
Date: Tue, 20 Oct 2015 09:37:00 -0000 [thread overview]
Message-ID: <20151020093741.GA17374@calimero.vinschen.de> (raw)
In-Reply-To: <0MIuft-1ZZdDB2IaP-002Y2r@mail.gmx.com>
[-- Attachment #1: Type: text/plain, Size: 4166 bytes --]
Hi Johannes,
Preliminaries: we need a copyright assignment from you before being able
to include your patches. Please see https://cygwin.com/assign.txt.
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
>
> Detailed explanation:
>
> In the context of Windows, there is a per-user directory for temporary
> files, by default specified via the environment variable %TEMP%. Let's
> allow to use that directory for our /tmp/ directory.
>
> With this patch, we introduce the special filesystem type "usertemp":
> 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 feature comes handy in particularly in scenarios where the
> administrator might want to write-protect the entire Cygwin directory
> yet still needs to allow users to write into the /tmp/ directory.
> This is the case in the context of Git for Windows, where the
> Cygwin (MSys2) root directory lives inside C:\Program Files and hence
> /tmp/ would not be writable otherwise.
You are aware that this breaks interoperability in some cases where
files are shared in /tmp, right? It's very important to stress the fact
that one user's /tmp is not the same as another user's /tmp when working
on the same machine in this scenario, e.g. via terminal services.
X server sockets won't be in the expected place, etc. Also, what about
/var/tmp, /var/log, /var/run, /dev/mqueue, /dev/shm?
Creating this kind of mount type only solves part of the problem in this
scenario. If the Admins insist to install the Cygwin directory
structure in an unexpected way, a full solution appears to be much more
extensive.
Wouldn't it be simpler to install a generic, writable temp dir and just
point to it via standard mount point?
As for the patch itself:
- The ChangeLog entry is missing.
> diff --git a/winsup/cygwin/mount.cc b/winsup/cygwin/mount.cc
> index 6cf3ddf..0b3dbdc 100644
> --- a/winsup/cygwin/mount.cc
> +++ b/winsup/cygwin/mount.cc
> @@ -1139,6 +1139,8 @@ mount_info::from_fstab_line (char *line, bool user)
> unsigned mount_flags = MOUNT_SYSTEM | MOUNT_BINARY;
> if (!strcmp (fs_type, "cygdrive"))
> mount_flags |= MOUNT_NOPOSIX;
> + if (!strcmp (fs_type, "usertemp"))
> + mount_flags |= MOUNT_IMMUTABLE;
> if (!fstab_read_flags (&c, mount_flags, false))
> return true;
> if (mount_flags & MOUNT_BIND)
> @@ -1163,6 +1165,21 @@ mount_info::from_fstab_line (char *line, bool user)
> slashify (posix_path, cygdrive, 1);
> cygdrive_len = strlen (cygdrive);
> }
> + else if (!strcmp (fs_type, "usertemp"))
> + {
> + WCHAR tmp[MAX_PATH];
> +
> + if (GetEnvironmentVariableW (L"TEMP", tmp, sizeof(tmp)) && *tmp)
- Maybe using GetTempPathW instead? It always returns a path.
> + {
> + DWORD len;
> + char mb_tmp[len = sys_wcstombs (NULL, 0, tmp)];
- len = sys_wcstombs() + 1
Alternatively, use tmp_pathbuf:
tmp_pathbuf tp;
char mb_tmp = tp.c_get ();
> + sys_wcstombs (mb_tmp, len, tmp);
> +
> + int res = mount_table->add_item (mb_tmp, posix_path, mount_flags);
> + if (res && get_errno () == EMFILE)
> + return false;
> + }
> + }
> else
> {
> int res = mount_table->add_item (native_path, posix_path, mount_flags);
- 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.
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-20 9:37 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 [this message]
2015-10-20 11:47 ` Johannes Schindelin
2015-10-21 18:23 ` Corinna Vinschen
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=20151020093741.GA17374@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-patches@cygwin.com \
--cc=johannes.schindelin@gmx.de \
/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).