Re: Mounting /tmp at TMP or TEMP as a last resort
On Thu, Sep 09, 2010 at 04:06:34PM -0700, Earl Chew wrote: >On 09/09/2010 2:16 PM, Pierre A. Humblet wrote: >>So, for example, if the user logs in interactively while a cron job (or >>another service) is running, /tmp may be mapped differently than if no >>cron job is running, because TMP may be defined differently in the >>service environment. That is not desirable. > >I believe that information is kept in Cygwin shared memory regions on a >per-user basis. I imagine there would other other unwanted >side-effects if this were not the case. Everyone: If this discussion is going to continue then please move to the Cygwin mailing list. We are not going to be applying the patch so further discussion is not going to be patch related. cgf
Re: Mounting /tmp at TMP or TEMP as a last resort
On 09/09/2010 2:16 PM, Pierre A. Humblet wrote: > So, for example, if the user logs in interactively while a cron job (or > another service) > is running, /tmp may be mapped differently than if no cron job is running, > because > TMP may be defined differently in the service environment. > That is not desirable. I believe that information is kept in Cygwin shared memory regions on a per-user basis. I imagine there would other other unwanted side-effects if this were not the case. Assuming this to be the case, services running as SYSTEM or another user cannot influence the mount decision of /tmp for the current user. So the only consideration is if there is a service running alongside the currently logged in user. 1. /tmp specified in /etc/fstab 2. /tmp present on filesystem. No difference in behaviour with proposed patch in these cases. 3. /tmp not present in either /etc/fstab or filesystem, and no TMP or TEMP No /tmp is available. Programs will have manage without it. 4. /tmp not present in either /etc/fstab or filesystem, but either TMP or TEMP present Without the patch, this is the same as case (3). Settings for TMP or TEMP are injected into the Win32 process via the User Environment Variables: http://msdn.microsoft.com/en-us/library/bb776899%28VS.85%29.aspx Thus the service-running-as-user and the logged in user would inherit the same values. I can see one way to subvert (4). It is possible for a service to run as a plain Win32 process, modify TMP (or TEMP), then launch the first Cygwin process which would then mount /tmp at the modified location. A similar scenario could occur the other way around too. I think these scenarios are not likely to occur often. Usually TMP and TEMP are set as User Environment Variables and don't get changed. If it's important to lock down the location of /tmp, then either create /tmp in the filesystem or create an entry in /etc/fstab. This is what you're required to do in the current implementation anyway because without it, no /tmp is made available (and bash will complain, etc). Earl
Re: Mounting /tmp at TMP or TEMP as a last resort
On 09/09/2010 21:53, Earl Chew wrote: > On 09/09/2010 1:03 PM, Dave Korn wrote: >>> but I think we >>> should keep the parsing of /etc/fstab as lean as possible; >> I don't understand why. How many times per second does /etc/fstab get >> parsed? > > I interpreted cgf's comment as not wishing to add to the amount of coupling > with /etc/fstab. > > /etc/fstab is already parsed for /usr/bin and /usr/lib, so in my mind > the additional query for /tmp doesn't seem to add significantly. Right, in case I wasn't clear, my question was really shorthand for "it can't just be a matter of cycle count, so what is the exact problem?" cheers, DaveK
Re: Mounting /tmp at TMP or TEMP as a last resort
- Original Message - From: "Dave Korn" To: Sent: Thursday, September 09, 2010 16:03 | On 08/09/2010 23:41, Christopher Faylor wrote: | > Corinna may disagree, | | Needless to say, I'm not Corinna! | | > but I think we | > should keep the parsing of /etc/fstab as lean as possible; | | I don't understand why. How many times per second does /etc/fstab get parsed? My problem with the original patch is that the mountinfo is kept per user, if my memory is correct, and /etc/fstab is parsed by the first process of a user. So, for example, if the user logs in interactively while a cron job (or another service) is running, /tmp may be mapped differently than if no cron job is running, because TMP may be defined differently in the service environment. That is not desirable. Corinna's suggestions are more appealing. If there are objections to using a /etc/profile.d/tmp-mnt.sh or an installer script, why not have /etc/profile (or such) create /etc/fstab.d/$USER on the fly if needed ? Pierre
Re: Mounting /tmp at TMP or TEMP as a last resort
On 09/09/2010 1:03 PM, Dave Korn wrote: >> but I think we >> should keep the parsing of /etc/fstab as lean as possible; > > I don't understand why. How many times per second does /etc/fstab get > parsed? I interpreted cgf's comment as not wishing to add to the amount of coupling with /etc/fstab. /etc/fstab is already parsed for /usr/bin and /usr/lib, so in my mind the additional query for /tmp doesn't seem to add significantly. Earl
Re: Mounting /tmp at TMP or TEMP as a last resort
On 08/09/2010 23:41, Christopher Faylor wrote: > Corinna may disagree, Needless to say, I'm not Corinna! > but I think we > should keep the parsing of /etc/fstab as lean as possible; I don't understand why. How many times per second does /etc/fstab get parsed? cheers, DaveK
Re: Mounting /tmp at TMP or TEMP as a last resort
On 09/09/2010 12:50 AM, Corinna Vinschen wrote:
> Apart from changing /etc/fstab or /etc/fstab.d/$USER by some installer
> script, why not just add a one-liner profile script along the lines of
>
> /etc/profile.d/tmp-mnt.sh:
>
>mount -f `cygpath -m "${TEMP}"` /tmp
That's a pretty good idea.
Some differences I can think of:
a. I suspect this will only be executed by an interactive shell (or one
with the right triggering command line options).
b. Other shells (eg tcsh) might have other ideas.
c. It won't be successful if the first invoked program is not a shell.
I also believe that bash(1) complains if /tmp is not available. This
would occur prior to executing the mount. A minor issue.
We've used Cygwin for a long time and haven't had the need to
use an installer script in the past.
Admittedly issues with the mount table (way back from 19.1!) have
always caused some difficulty which we've muddled around, but
the recent behaviour with the automounting of /usr/bin and /usr/lib
with respect to the installation root is a great innovation which
has made all those problems simply go away.
Given that TMP and TEMP are standard Windows environment variables:
http://technet.microsoft.com/en-us/library/ee156595.aspx
it seemed reasonable to have /tmp be equivalent as a default case.
This approach has a side-effect of personalizing the location
of temporary files because each user has a different setting for
TMP (and TEMP).
Earl
Re: Mounting /tmp at TMP or TEMP as a last resort
On Sep 8 15:59, Earl Chew wrote:
> On 08/09/2010 3:41 PM, Christopher Faylor wrote:
> > Thanks for the patch but I don't think this is generally useful. If you
> > need to mount /tmp somewhere else then it should be fairly trivial to
> > automatically update /etc/fstab. Corinna may disagree, but I think we
> > should keep the parsing of /etc/fstab as lean as possible; particularly
> > when there are alternatives to modifying Cygwin to achieve the desired
> > result.
>
> Yes, I understand what you're saying.
>
> In our situation, we prefer an out-of-the-box deployment. (We're
> essentially trying to get to a "untar this and use it" state).
>
> That said, I don't think it's possible for /etc/fstab to inspect
> environment variables, so manipulation of /etc/fstab would
> require the assistance of some other script to edit /etc/fstab on
> the fly --- and even then it would be difficult to track changes
> to the environment variables.
Apart from changing /etc/fstab or /etc/fstab.d/$USER by some installer
script, why not just add a one-liner profile script along the lines of
/etc/profile.d/tmp-mnt.sh:
mount -f `cygpath -m "${TEMP}"` /tmp
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: Mounting /tmp at TMP or TEMP as a last resort
On 08/09/2010 3:41 PM, Christopher Faylor wrote: > Thanks for the patch but I don't think this is generally useful. If you > need to mount /tmp somewhere else then it should be fairly trivial to > automatically update /etc/fstab. Corinna may disagree, but I think we > should keep the parsing of /etc/fstab as lean as possible; particularly > when there are alternatives to modifying Cygwin to achieve the desired > result. Yes, I understand what you're saying. In our situation, we prefer an out-of-the-box deployment. (We're essentially trying to get to a "untar this and use it" state). That said, I don't think it's possible for /etc/fstab to inspect environment variables, so manipulation of /etc/fstab would require the assistance of some other script to edit /etc/fstab on the fly --- and even then it would be difficult to track changes to the environment variables. Thanks for the quick feedback. Earl
Re: Mounting /tmp at TMP or TEMP as a last resort
On Wed, Sep 08, 2010 at 03:27:14PM -0700, Earl Chew wrote: >We have an installation that we deploy to a bunch of workstations. We prefer >if the installation uses the temporary file directory that Windows has already >allocated for the user. > >The entry for /tmp in /etc/fstab, or the directory /tmp, is preferred. >If neither is found, the patch mounts /tmp at the directory indicated >by the environment variable TMP or, if that is not set, TEMP. The patch >does nothing if neither environment variable is set. Thanks for the patch but I don't think this is generally useful. If you need to mount /tmp somewhere else then it should be fairly trivial to automatically update /etc/fstab. Corinna may disagree, but I think we should keep the parsing of /etc/fstab as lean as possible; particularly when there are alternatives to modifying Cygwin to achieve the desired result. cgf
Mounting /tmp at TMP or TEMP as a last resort
We have an installation that we deploy to a bunch of workstations. We prefer
if the installation uses the temporary file directory that Windows has already
allocated for the user.
The entry for /tmp in /etc/fstab, or the directory /tmp, is preferred.
If neither is found, the patch mounts /tmp at the directory indicated
by the environment variable TMP or, if that is not set, TEMP. The patch
does nothing if neither environment variable is set.
Earl
--- mount.h.orig2010-03-18 07:57:09.0 -0700
+++ mount.h 2010-09-08 11:10:23.218802900 -0700
@@ -140,6 +140,7 @@
int nmounts;
mount_item mount[MAX_MOUNTS];
+ static bool got_tmp;
static bool got_usr_bin;
static bool got_usr_lib;
static int root_idx;
--- mount.cc.orig 2010-03-30 03:03:09.0 -0700
+++ mount.cc2010-09-08 11:35:27.765251900 -0700
@@ -45,6 +45,7 @@
#define isproc(path) \
(path_prefix_p (proc, (path), proc_len, false))
+bool NO_COPY mount_info::got_tmp;
bool NO_COPY mount_info::got_usr_bin;
bool NO_COPY mount_info::got_usr_lib;
int NO_COPY mount_info::root_idx = -1;
@@ -390,6 +391,24 @@
MOUNT_SYSTEM | MOUNT_BINARY | MOUNT_AUTOMATIC);
}
}
+
+ if (!got_tmp)
+{
+ char tmpdir[PATH_MAX];
+ if (root_idx < 0)
+ api_fatal ("root_idx %d, user_shared magic %p, nmounts %d", root_idx,
user_shared->version, nmounts);
+ char *p = stpcpy (tmpdir, mount[root_idx].native_path);
+ stpcpy (p, "\\tmp");
+ if (GetFileAttributes (tmpdir) != FILE_ATTRIBUTE_DIRECTORY)
+{
+ const char *tmp = getenv("TMP");
+ if (!tmp)
+ tmp = getenv("TEMP");
+ if (tmp)
+ add_item (tmp, "/tmp",
+ MOUNT_SYSTEM | MOUNT_BINARY | MOUNT_AUTOMATIC);
+ }
+}
}
static void
@@ -1342,6 +1361,9 @@
if (i == nmounts)
nmounts++;
+ if (strcmp (posixtmp, "/tmp") == 0)
+got_tmp = true;
+
if (strcmp (posixtmp, "/usr/bin") == 0)
got_usr_bin = true;
