Re: Errors using configure when building packages
Sinkler, Wharton wrote: I've got a new Cygwin installation on Win7, which has issues with configure, the first step of building packages from source (I've seen this with ImageMagick, libtiff and others so it's not specific to the package I'm installing). It seems to sporadically be unable to remove a file 'conftest.exe' which is compiled in the tests within configure. This shows up during configure as: rm: cannot remove 'conftest.exe': Device or resource busy The configure will then fail completely when this causes a critical test to fail. I suspect that this might have something to do with slowness to release an in-use file (the conftest.exe) in the Win7 operating system. I've searched the archives and don't see this exact issue showing up in previous posts. Have others experienced this problem? Is there a fix which will allow me to complete building these packages? I ran into a similar problem on linux - but was unable to describe it to the point where others could reproduce it -- so I manually worked around it in each case where it happened, until some SW-update to the autoconf-stuff made it go away. It also happened in multiple packages, so wasn't specific to any one -- but it also happened on *linux*. The problem is that somehow the information for "conftest.exe" will be *in* the directory "conftest.exe" with some temporary name. It's really a weird one -- but it happened with different files (where the actual file was in a directory that had the name of the file, and the actual file being in the directory with some name like "out". It happened with multiple SW products that I would build, but not most. Have no idea what caused it but do know that updating the autoconf-related SW eventually made it go away. Sorry can't be more precise, but when I tried reporting it as a bug, different dev-teams gave up and suggested re-formatting and re-installing linux. So helpful! Occasionally I run into weird problems -- because of how my system is setup -- but are still caused by bugs in the underlying SW -- like making perl, completely failed for a few years on my system because I had a RAID 50 where the "optimal write size" was 12*64KB (3 RAID-5's that were 4*64KB/stripe). The underlying Gnu DB library failed (probably still does, as no one wanted to try to fix it, was designed around the assumption that the optimal-write-size would always be a power-of-2 -- which it is not. I even told how to reproduce and test for it (using a VM), but it got ignored... ;^/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: /dev/stderr problem
Eric Blake wrote: On 10/17/2016 01:32 AM, Thorsten Kampe wrote: * Thorsten Kampe (Mon, 17 Oct 2016 08:25:13 +0200) the following bash script results in a different output when redirected to a file. ``` printf "FIRST LINE\n" > /dev/stderr shopt -os xtrace printf "SECOMD LINE\n" > /dev/stderr Cygwin treats '> /dev/stderr' as a request to truncate /dev/stderr (or, for that matter, any opening of a file under /proc/self/fd). Other platforms treat that as a special file that can never be truncated, but is instead reopened at the same offset. Maybe cygwin can be taught that opening a file through /proc/self/fd should preserve rather than reset offsets, but it will be a tricky patch, and someone has to write it. --- Is /dev/stderr a POSIX special name that one should expect that rewinding is disallowed or ignored? Good analysis, BTW, that sure would have puzzled me. -l -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: intelligent following of directions, or following them by rote...
Erik Soderquist wrote: On Fri, Oct 7, 2016 at 6:04 PM, Linda Walsh wrote: As for package maintainers needing some specific behavior -- if a backdoor to your system was part of the "base" system, would you If there is a "back door" in a base package, that is a security failing and needs to be reported and fixed --- I think you miss the point -- the point would be whether or not you believe you "need" to install and use it "as is", or if consider that maybe you want a different, "fixed" version? Whether you fix it or someone else does often depends on turn-around time and ease of user building, but I think you answer the question -- you'd take action to replace the code *rather* than living with it. Hey, I never accused, directly or obliquely, you of not using your head... ;-) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: intelligent following of directions, or following them by rote...
Brian Inglis wrote: On 2016-10-07 16:04, Linda Walsh wrote: ... what affect on the cygwin installation would be if you didn't install the base vim package?Just a thought. Type v inside a PAGER (e.g. less or more). Run an editor on the current (long) command line in readline or shell history. Edit a commit message in any VCS. Edit crontab entries. You can change some of these if you prefer ed or emacs (EDITOR, VISUAL), and ex is a symlink to vi (vim-minimal). --- Good point -- but none of those should cease to run if you are putting your own "well working" version of vim it its place -- which was where this got started in someone desiring to put their own version on their machine. FWIW, I've run my own compiled Gvim version on linux for years and had fewer problems. My linux distro supplies a version that links with various languages (ruby, python, perl, etc) -- but they don't use run-time dynamic loading, so if something happens and the versions don't match (they must match, even, the patch-levels) then neither vim nor gvim can be used as an editor. Such was sufficient reason for me to build and replace the OS-instance of vim/gvim. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Blocking a base package from installing
Hans-Bernhard Bröker wrote: If you do set up such an explorer menu entry, it'll do whatever you tell it to. --- There is already such an addon for vim -- and it launches it from the system-standard location. Putting a copy in /usr/local won't be called. If you want to replace the main copy and all it's purposes/uses, you need to overwrite the system copy. It'll only end up "of course not" working if you "of course" configure things differently than you actually wanted to. But why would anyone do that? --- Why would you install a system copy of vim anywhere other than in the system location? To install it in /usr/local would prevent it from working normally -- why would anyone do that? Did it occur to you that the system really has to support much more varied use cases than your own particular corner case? --- Not on my system. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
intelligent following of directions, or following them by rote...
Andrey Repin wrote: Greetings, Linda Walsh! Achim Gratz wrote: Now, that last question of yours: No, the package manager should never allow you to not install a base package. These are in category "Base" precisely so the rest of the system can rely on the functionality provided. [snip] But back to the 1st Q. What other programs will fail to work if the base-version of vim isn't installed? The question is not about vim... --- But it is about vim. That's the package the user wanted to install their own version of. There is such a thing of not following rules, guidelines and instructions without thinking about the situation. If you follow things without thinking, you'll often end up screwing yourself in the long run. How many installer packages tell you to accept their "default" (always says "recommended") vs. choosing specifics? The defaults often contain items you don't want while not providing things you do. The default for Nvidia drivers is to install 3D-drivers even if you don't have a 3D screen and goggles. What's intelligent about that? It's vim only now, tomorrow it'll be something else. --- Right, Today, it's taking a walk by the seashore, tomorrow it's jumping off a cliff. Um.. no! If you do some research and/or know a bit about what you are doing, you can stop before you jump off the cliff. You have to stop and draw the line somewhere, if you, as a package maintainer, want a predictable behavior for all future installations. --- But you can't get predictable behavior now. It's running on windows (1st problem), 2nd, it doesn't follow MS-Win conventions. 3rd, Windows sends out incompatibility patches on a regular basis. Documented features in windows are ignored and overwritten in cygwin -- so you already have unpredictability. I haven't installed any updates to my system since the new user-auth/password stuff was added in because the stuff I have works now with a NT4 type samba domain controller. Above that is NT5 w/active directory -- installing LDAP and losing _easy_ control over what I already have (enough research and struggle and I might get it back, but I have other things to do that have higher priority. As for package maintainers needing some specific behavior -- if a backdoor to your system was part of the "base" system, would you stick to your "line" and install it? If you say "no", then you are using your brain and not doing it by rote. If you can do it, why shouldn't other people be able to do it on their system(s)? Another simple example -- where does one install cygwin? In the /cygwin dir (Windows says not to do that -- it wants programs in "program files" or "program files (x86)). Who do you follow? How about whether you install it in /cygwin or in "/" so files @ /etc will be in \etc on windows? Cygwin recommends installing it in /cygwin, but at one point (don't know about now), most of the devs admitted that they installed it in "/" for their personal use. Anyway, thinking about what you are doing and why things are they way they are, is important -- which is why I asked, what affect on the cygwin installation would be if you didn't install the base vim package? If you don't know the answer, then maybe the defaults are for you, but if you have an idea of what vim does and how it might be used to run the rest of cygwin, then you might experiment to find if things fail or continue to work w/o the base-vim. Just a thought. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Blocking a base package from installing
Achim Gratz wrote: Now, that last question of yours: No, the package manager should never allow you to not install a base package. These are in category "Base" precisely so the rest of the system can rely on the functionality provided. --- And what other programs will stop functioning if vim is not installed? If I compile and install a version of vim on my system, why would I want to put it in a location like /usr/local where it might not be used -- all the time? I'm the only user on my system -- whether I run as a user or as root, or whatever, I'm not doing this for someone else. If I try to edit a file using 'vim' from the explorer menu, will it invoke my vim in /usr/local -- of course not. Installing some private copy where all the rest of the system will ignore it, is asking for headaches. How many people do you think are installing cygwin on servers to be used by many people, vs. their personal machines to only be used by them? But back to the 1st Q. What other programs will fail to work if the base-version of vim isn't installed? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Blocking a base package from installing
Achim Gratz wrote: Chris Sutcliffe writes: I'm using a self compiled vim, so I uninstalled vim-minimal. Every time I run setup to get the latest updates, setup attempts to reinstall vim-minimal - is there a way to make setup ignore vim-minimal? Yes, at least two. 1. Build a proper package and give it a higher version number than Cygwin's own Vim. 2. Fake the installation of vim-minimal in /etc/setup/installed.db and give that fake installation some high version number. --- Both of which are "lying" to the package manager, to get it to NOT install an inferior (from the standpoint of not containing the user-desired modifications/features) package. It should be possible to "LOCK" a package (base or not), to prevent it from being removed/updated/installed or changed by setup, no? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Native symlinks and setup.exe
Thorsten Kampe wrote: Tar's task is to unpack what's in the archive. So converting is out of question. You can ask the maintainer of the affected packages to create the symlinks in the postinstall script. --- Is it a "special" tar, or is it the normal version of tar that runs under Cygwin? I would assume that the install scripts run under the cygwin-environment. That includes paying attention to the global value of CYGWIN. If you set CYGWIN in your windows environment variables (recommended), then it will always be set before any cygwin or setup program runs. Setup isn't going to explicitly clear CYGWIN of its values, unless they *happen* to be "invalid" -- and even then, I doubt it would modify the user-set value of CYGWIN. When I install programs, tar has always honored the global value of CYGWIN I set in the system env vars. (System is recommended over User Env, since cygwin can run as multiple users, and if you want consistent cygwin operation, you should set it before any cygwin processes have started. Is someone claiming that values in the System-Env var CYGWIN are ignored by programs being installed? NOTE: it is known and considered a "feature", that Cygwin ignores MS-mountpoints mounted with mountd or linkd (link directory) and treats them as symlinks. This prohibits user control and redirection of installed programs and disables the linux equivalent of mount --bind "thisdir" "onthisdir". -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unknown+User Unix_Group+505 on smb shares in a domian
Wayne Porter wrote: This is how it is currently set up. I can log in to the server via ssh or use the current method, which is to map the network share using my account credentials that they have set up for me. This works just fine in Windows and for the most part in Cygwin. I can read/write from the files but vim opens all files in read-only mode and I have to save using :w! I hate it when that happens! ;-) So the files you are trying to access are from your own local login on those machines? Is there a reason why the login you have on those machines is a machine-local login? I.e. I believe you said earlier, that the machines are joined to the domain. Say your domainname="domain", and you have a domain login "wporter". Can you login (or can anyone login) using domain credentials to those linux machines? OR can you arrange to be able to, then copy your files on those machines to your domain account. If the remote files are owned by you and you are logged into your domain account on your usual cygwin machine, then the permissions should match. There's alot of permissions/privileges on Windows that don't map to anything on Linux or cygwin. So while cygwin can compare the access rights in the things it knows about, it can't begin to know about various windows permissions and controls that might allow you to override the normal file-access controls. If you can't login to the linux machines on your domain account, could you get root access long enough to chown the files over to your domain account? If you can't login to the linux machines w/your dom account, authenticating your login w/the domain server might not be enabled. Might also have to create home directory for your domain account manually. If they need to setup login checks for domain logins on those machines, they need to add some windbind rules to the /etc/pam.d/common-... Just to give you an idea (they should figure out the order by looking at relevant docs): grep winbind /etc/pam.d/common* /etc/pam.d/common-account:account sufficient pam_winbind.so /etc/pam.d/common-auth:auth sufficient pam_winbind.so /etc/pam.d/common-password:password sufficient pam_winbind.so /etc/pam.d/common-session:session sufficient pam_winbind.so -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unknown+User Unix_Group+505 on smb shares in a domian
Wayne Porter wrote: Essentially you have a bunch of users on different machines that aren't sharing their files under any common (or shared) security authority (like a single domain). Until you persuade the owners of those linux machines to move the linux machines under a common security authority (like a windows domain) and moving the user accounts into the domain. Each local account would have to be moved to a domain account with the files under each machine-local account being moved (or "chown'ed") to the new, corresponding domain account). The shares are mapped and working just fine in Windows. To IT, there isn't anything that needs to be done. It just happens that Cygwin, which I'm the only one using, maps the Windows mapped drives to an unknown user account and makes using it difficult. --- Working in windows where? What does "working just fine in Windows" mean? That people in explorer on your machine have read+write access to the linux-shares? Or do you have domain access to the machines running Windows? Are those machine in your Domain or are they outside your domain like the linux machines? This is an organizational problem that has nothing to do with cygwin, but whether windows and linux machines are using domain or machine-local security. Until your linux machines and their local user become part of the domain, you can't expect any "write" privileges granted to you under the domain to work on the linux machines. I have write permissions on those machines from Windows. Cygwin thinks I don't so files are opened in read-only mode but when I force them to be written, it works. I'm not sure if maybe I left this out of my initial information, but these are shares that are mapped in Windows on login and there are no issues there, but once I open Cygwin, I don't appear to have write access even though I do. --- If you have write access, then you are saying the permission are not displaying properly in Cygwin. So do you have the same, *actual* access in Cygwin as windows (ignoring what permissions may be displayed)? It could be that you have domain-admin access and are overriding listed permissions on remote machines. If it's the case that your user doesn't have R+W access, but you are a domain admin, you might just be overriding the write-restrictions in windows as well as cygwin. When mapping the drives in Windows, a username and password are given. Is there no way to let Cygwin know about that username without joining the servers to the domain? I know that this setup isn't ideal, which is why I'm trying to find a work-around. --- Bingo! You need to try something like "runas [alternate credentials + alternate password] net use W: ..." That might work... but is really icky, since you can't easily automate that without storing the password in clear-text in some file in your profile... that's not a good solution. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unknown+User Unix_Group+505 on smb shares in a domian
Wayne Porter wrote: The server that the W: drive is mapped on is not using domain accounts. As far as I know, all Linux servers we have are running local accounts. Is there something I can set in my local /etc/passwd to convince Cygwin to map it to my user account? --- Let me phrase this differently. The linux accounts that are not in your domain and are under private user-names, are NOT something that you have "write" permission to. It sounds like those users (users outside your domain -- and not within your administrative group) have allowed "anyone" to have read access, but it makes sense that they wouldn't trust "anonymous" (that's you, if you haven't authenticated against their machine). You seem to be asking for access to files owned by people outside your group (or maybe outside your company, for that matter, it's not known). The Domain is a means to provide common trusted access to a group of people who have agreed to honor each others' permission settings. Right now, the linux people are not in a common-trust group, so you can't force your wanted access upon them. Until you and their machines share a common security token (the Domain token), you can't have shared permission settings. Alternatively , you might be able to convince the linux people to give you an account on each linux machine, and use that login when attaching to a share on that linux machine -- but that would be a pain. Certainly, if they agreed to use a common domain and shared things with other domain users, that would be easier, but until they agree to be in a common domain, you can't force your desired access upon them. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unknown+User Unix_Group+505 on smb shares in a domian
Wayne Porter wrote: The server that the W: drive is mapped on is not using domain accounts. As far as I know, all Linux servers we have are running local accounts. Is there something I can set in my local /etc/passwd to convince Cygwin to map it to my user account? --- If the linux servers are not exporting files under the domain account, then they files are not part of the 'domain' but owned only by the username on that specific linux-machine. It sorta sounds like the linux server may not even be in the domain -- in which case mentioning domains only confuses the issue. Essentially you have a bunch of users on different machines that aren't sharing their files under any common (or shared) security authority (like a single domain). Until you persuade the owners of those linux machines to move the linux machines under a common security authority (like a windows domain) and moving the user accounts into the domain. Each local account would have to be moved to a domain account with the files under each machine-local account being moved (or "chown'ed") to the new, corresponding domain account). This is an organizational problem that has nothing to do with cygwin, but whether windows and linux machines are using domain or machine-local security. Until your linux machines and their local user become part of the domain, you can't expect any "write" privileges granted to you under the domain to work on the linux machines. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unknown+User Unix_Group+505 on smb shares in a domian
Wayne Porter wrote: My system is joined to a domain and is connected to multiple servers via mapped network shares in Windows. All of the windows servers allow read/write access to all files, but the Fedora servers all open with read-only access. I can still write to most files in vim by specifying :w! so it's not like I can't do anything, it just becomes an inconvenience. d---r-x---+ 1 NT SERVICE+TrustedInstaller NT SERVICE+TrustedInstaller 0 Sep 26 08:50 c drwxrwx---+ 1 Administrators Domain Users0 Sep 14 11:57 i drwxrwx---+ 1 SYSTEM SYSTEM 0 Sep 26 12:55 j drwxrwx---+ 1 Administrators Domain Users0 Sep 27 07:55 m drwxr-xr-x 1 rootieng6_root 0 Jul 12 04:04 v drwxrwxr-x 1 Unknown+UserUnix_Group+505 0 Sep 21 09:41 w drwxrwxr-x 1 Unix_User+99Unix_Group+101 0 Sep 21 15:20 y Can anything tell me what I might be missing? --- Does the linux server, where cygdrive "w" is located have the share/files owned by a domain group? I.e. On any system (win or lin) you can have domain accounts and local accounts. In order to share files with the rest of the domain, files on the server for drive 'w' have to be owned by a domain account. It looks like the files are owned by a linux-local account. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Use of SHELL env var by login
Andrey Repin wrote:
Greetings, Linda Walsh!
Windows *doesn't* use "SHELL" to set your command line, it uses
COMSPEC.
Do note I didn't mention any specific variable names.
---
Indeed -- wanted to be explicit for those not know that the space
in-between the lines is important! ;-)
And I've explicitly outlined exactly the case you are describing in your post
- integration.
If you indeed have "more other" applications (native ports of certain tools,
which still use environment as a go-to reference sources), then by all means,
do what you find best for you.
I do that all the time, too, but I also have Cygwin itself configured to match
the environment I expect to have. Just to avoid issues.
---
Yup -- I use the same site-wide login scripts (for me & root and
multi-machine) on linux and cygwin and regularly make sure to copy and test
them on both -- not to mean I don't have cygwin specific sections that
key off OS:
if ! type -f cygwin 2>/dev/null ; then
read SYSTEM_KERNEL HOSTNAME OSTYPE <<<"$($_prg_uname -sno)"
if [[ $OSTYPE =~ Cygwin ]]; then sub cygwin () { return 0; }
else sub cygwin () { return 1; }
fi
export -f cygwin
fi
# and some cygwin-only defs in /etc/local/cygwin, like
alias gvim='setsid gvim' # ensure win-native vim backgrounds
properly
and a version of "mklink" that runs in bash and uses the
*nix syntax of "mklink " (and auto-handles directories)
#!/bin/bash
#set -x
shopt -s expand_aliases extglob sourcepath
##
## func to help determine if we were called as script or lib &
## not dirty env if called as lib
##
function conditional_setprog {
local lprogpath="$0"
[[ $lprogpath =~ .*bash.* ]] && { lprogpath="$1"; shift; }
local lprog="${lprogpath##*/}" lprogdir="${lprogpath%/*}"
local lprogname="${lprog%.*}"
if [[ $lprogname =~ errnos ]]; then
declare -g prog="$lprog" progpath="$lprogpath" progname="$lprogname"
fi
}
conditional_setprog "$@"
#include stdalias
#include errnos
# -- include needed bits for fewer includes
alias intConst=declare\ -ir sub=function my=declare int=declare\ -i
intConst ENOENT=2 EEXIST=17 ENOSYS=38 ENOMSG=42
sub mklink () {
sub err_ex {
my err="${!1}" msg="$2"
echo "$msg" >&2
return $err
}
if (($#!=2)) && [[ ! $0 =~ bash ]] ; then
echo "mklink <to-path|.> # (destination must not exist)" >&2
fi
local src=${1%/.} dst=${2%/.}; src=${src%/}
[[ $dst == . ]] && dst="${src##*/}"
[[ -e $dst ]] && {
err_ex EEXIST "Destination, \"$dst\", already exists."
return
}
[[ -e $src ]] || {
err_ex ENOENT "Source, \"$src\", does not exist."
return
}
local dest_type="unknown"
if [[ -f $src ]]; then dest_type=""
elif [[ -d $src ]]; then dest_type="/d"
else
err_ex ENOSYS "Cannot determine src, \"$src\" as file or dir"
return
fi
local winsrc windst
printf -v winsrc "%s" "$(cygpath -wl "$src")"
printf -v windst "%s" "$(cygpath -wl "$dst")"
# windows reverses everything *nix
# just to be different from CP/M which modeled Unix
printf -v cmd 'cmd /c mklink %s "%q" "%q"' "$dest_type" "$windst" "$winsrc"
eval "$cmd"
(($?)) && err_ex ENOMSG "Windows return unexpected status($status)"
}
export -f mklink
(($#==0)) || [[ $0 =~ bash ]] || mklink "$@"
# vim: ts=2 sw=2
--
-linda
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Use of SHELL env var by login
Andrey Repin wrote: In the absence of /etc/passwd, setting SHELL is the right way to set your login shell. One of the right ways, I'd say. If your aim is the integration of both environments, you MAY set variables, but if you then start a login shell, they may be voided by the startup scripts. I would advise using "more other" ways to configure Cygwin, i.e. using SAM DB comment field. --- Windows *doesn't* use "SHELL" to set your command line, it uses COMSPEC. So setting SHELL won't do MS programs any good. I set mine for the benefit of some non-MS programs that ran windows natively so I could have an easier time in some of my own scripting. The form C:/bin/bash.exe was *NOT* set by cygwin prompting me to set it -- since it cygwin wanted a windows path it would only have accepted C:\bin\bash.exe. If it wanted a non-windows, pure-posix-like path, it would have complained about referring to /c as "C:". It's the unsupported "middle-ground" path that works in win32 and cygwin -- but my cygwin is install @ '/' not /c/ (though they end up at the same point) -- I mention the C: drive primarily for windows programs (if they are on another drive, the path /bin/bash.exe is processed as being on the "current drive", so in program like the _windows_ _versions_ of 'vim/gvim', that "cd" to the same directory as the file you are editing, also end up changing drive letters (a network drive in my setup) where /bin/bash doesn't work (as /bin/bash would only work when drive 'C' is current). You *can* set COMSPEC to something other than "cmd.exe", but I would not -- since some windows program depend on COMSPEC to be cmd.exe ( :-( ). Setting SHELL will have no effect on Microsoft windows program -- it may on some non-MS programs running on windows, but i've not found it provided sufficient benefit for the troubles. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: setup.exe : proxy auto-configuration script without IE ?
Jérôme Bouat wrote: Hello, I'm using cygwin on a thin desktop computer which has limited disk storage. The network configuration of setup.exe relies on the proxy auto-configuration script of IE. --- Actually, it doesn't "rely" on it, it offers to use whatever "IE" is set to instead of a direct-connection, in the belief (I believe), that most users will have IE configure -- if for no other reason, that it is the only browser that will be able to get anything downloaded to their system -- so if direct doesn't work, then IE almost has to be configured to access the internet to download *anything*. However, when a package is downloaded, it seems it is stored twice : one time into the IE disk cache and one other time into the cygwin packages disk cache. ??? What makes you think it is downloaded into the IE disk cache? I don't think it should be -- as AFAIK, it doesn't use IE to download anything, it just copies the settings so it can use the same settings. If you can't access the internet, how would you download anything to your system? If you need a special proxy, wouldn't you have configured IE with the special proxy so it can download anything else? Is there a way to make setup.exe understand the auto-configuration script without any web browser ? --- As far as I know, it does. What makes you think it is using IE's cache? You might configure IE to empty its cache when it exits, that way you won't see any false positives. -l -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Use of SHELL env var by login
Ernie Rael wrote: I just moved the cygwin installation. The "last" peculiarity I ran into was that the login shell, with the shortcut "F:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -", a ps showed /cygdrive/c/cygwin64/bin/bash instead of /usr/bin/bash I tracked this down the the windows setting for SHELL, the one you get to from windows' SystemProperties dialog, which was C:/cygwin64/bin/bash. The /etc/passwd file specifies /bin/bash. I don't think cygwin sets the Windows SHELL variable in the registry. My SHELL value in the System section is 'C:/Bin/Bash.exe', which isn't a cygwin-looking path (looks like something I set). Are you sure you didn't set it in the past sometime? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: moving Cygwin64 to another drive
Ernie Rael wrote: On 9/23/2016 4:28 PM, Brian Inglis wrote: On 2016-09-23 17:11, Ernie Rael wrote: I found a thread, https://cygwin.com/ml/cygwin/2015-04/msg8.html, from last year where Corinna suggests the following (which works for her; she notes YMMV) robocopy C:\cygwin64 F:\cygwin64 /e /purge /z /copyall /sl On Win7, I'm on a old cygwin installation (thought I'd copy to more spacious disk before updating) I tried this command after ssh to an admin account, but the command terminates. Not sure if it is important, but are you on the old machine, trying to copy local files to the new machine? Wasn't clear. with 100%New File 210shells 100%New File1595ssh_config New File 668 ssh_host_dsa_key 2016/09/23 14:54:53 ERROR 5 (0x0005) Copying File C:\cygwin64\etc\ssh_host_dsa_key Access is denied. where $ ls -l ssh_host_dsa_key -rw--- 1 cyg_server Administrators 668 Apr 20 2014 ssh_host_dsa_key I don't know much about windows. Any ideas on how to get this to work? Run robocopy as admin from an elevated command shell (bash or cmd) with Administrator privileges. Simply running as admin doesn't solve the problem. --- Yeah... I had a similar problem. Wanted to copy my Win7 cygwin install to another machine (WinXPx64). I also had problems with permission denied as an admin -- in my case, I think they were common cygwin DLL's. I think they were inuse -- and somehow that prevented them being copied. In my case, I was aided by having the other machines 'C' drive network mounted on Z:\. I was able to copy the couple (3 actually) of files that failed, manually, to old-machine's /tmp. There they weren't files that would be in use && then I could copy them across the net with anything. Since both machines had write access to each other's C: drive, I copied the files from old's /tmp to the bin & lib directories where these files lived. Once that was done it started functioning. Maybe that will give you some ideas? I was sorta in the dark as to what was causing the failure as well, so I poked about... ;-) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can you modify how Cygwin prepends domain name to username?
Carl wrote: Hi Linda, The plus character is the default separator for mkpasswd. In the help for it (mkpasswd -h), you will see -S,--separator char For -L use character char as domain\user separator in username instead of the default '+'. --- ??? Really? But how is that compatible with Win's USERNAME? ... I even use Domain\User on my linux domain server! So that would conflict, by default. When I login to linux from win, it logs in as Domain\User. Not entirely right for a PDC but at least somewhat consistent. Domain+User would be entirely broken. Yes -- I have added '\' to my allowed userID set on linux in /etc/login.defs. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can you modify how Cygwin prepends domain name to username?
Carl wrote: ADUNSW+root:*:2149521262:2147484161:U-ADUNSW\root, S-1-5-21-1140405718-358989843-3445714273-2037614:/home/root:/bin/bash --- Where does the '+' come from? Is that in Win10 or some newer domain control software? I'm running Windows 7, and cygwin uses the same naming conventions as the OS. I.e. in Windows, outside of cygwin, my domain logins look like "Domain\user". So in my /etc/passwd file, I see the same thing: Domain\user. I would be nervous to change the form in /etc/passwd to something different from the OS's name for the account, but it might make no difference. How does your local Win OS name such accounts? I.e. if I use Process Hacker, it can show the user account for each process, as obtained from Windows. It always shows Domain/user for the non-local users running programs. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The Cygwin User Guide on path names
Andrey Repin wrote:
Also, @ Linda, the string escaping is done by the shell before passing
arguments to the command, as I understand.
If I'm starting an application not from shell, the app, being a good citizen,
should not second-guess the arguments it is given.
---
Absolutely. Don't get me wrong. I am NOT for removing
functionality or compatibility. If the Winpaths work for you
in your situation, I am all for keeping them working! No reason
to break previous compatibility needlessly. Way too often, developers
are throwing away previous compat. because its convenient, to make
it harder for the user to maintain & control their machine.
I usually find the forward slashes easier to use because
of the quoting issue -- as I used ls for an example. Same would
apply to diff though. I.e. -- in bash, if you type
> diff C:\tmp\file1 C:\tmp\file2
It won't do what many might think it 'should', -- it will
try to compare "C:tmpfile1" & C:tmpfile2, with the backquotes
removed before diff or patch ever see the filenames.
You have to be careful to add extra quoting if you use Winpaths,
like:
> diff 'C:\tmp\file1' 'C:\tmp\file2'
If you used the unix path format, and have your cygdrive prefix =
'/', then you can type the above like:
> diff /c/file{1,2}
Which involves alot less typing (if 'c' is your root drive and you are
on the same drive, you could leave off the '/c' above to get:
> diff /file{1,2}
Which is even less typing... Personally, I like the shortest
format that works! But that doesn't mean longer forms shouldn't work
as well!
-l
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The Cygwin User Guide on path names
Andrey Repin wrote: Greetings, Ken Brown! The documentation also says, "The usage of Win32 paths, though possible, is deprecated" I wonder if this should be strengthened to say something like, "The usage of Win32 paths, though possible, is strongly deprecated and may be removed in a future release of Cygwin." That would be the day Cygwin die for me. -- With best regards, Andrey Repin Wednesday, August 24, 2016 12:50:55 Sorry for my terrible english... --- Curious -- but why? How do you make use of win32 pathnames ( "C:\bin" versus "/bin" or "/c/bin" or "/cygdrive/c/bin" ) depending on how your cygwin is configured). I'm wondering if maybe there is a misunderstanding? For the most part -- many cygwin apps may not work correctly if given a win32 path in the same place you'd put a *nix path due to the backslashes being turned into quote sequences. I mean, you can't type: ls C:\bin (instead of ) ls /c/bin and have it work, since the first would turn into: "ls C:bin" (or if the \b is taken as an escape sequence, it rings the bell, so it could be translated as "ls C:\008in". So I'm wondering where you know the backslash form would always work and wouldn't be mangled "somewhere"...? (If you see what I mean?) *cheers* -linda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Please explain how to add to a thread in this mailing list
Andrey Repin wrote: The problem is not the lists or subscription. The problem is that you are using gmail web interface. It's hopelessly broken and is unlikely to be fixed any time soon. --- While it's possible the gmail web interface can be misconfigured, I find that it usually redirects replies consistently with what I'm wanting. Though, of note -- I'd have to test as I don't usually use the gmail interface, it's _probable_ that if you hit 'reply' to a user in the gmail-lists interface, that it will reply to the group instead of to the user. There have been different interfaces on google for reading 'email' and those interfaces have changed over time. But at some point, for example, simply hitting reply might go to the group in the google-lists interface, but would go to a single user in the mail (not list) interface. Lists are built on top of the email interface, and different email readers don't always use the same conventions for these things -- often because people want different behaviors in different situations. How a list is displayed, or if it is displayed as a list at all, is determined by your email reader. References are used by email-processing software to allow the display of 'threaded conversations'. Reference headers headers in email are usually hidden because they intended to be read and added by the software -- not by users. Since I don't use gmail as my primary email client, I'm not familiar with all of its configuration options -- but the best thing to do is to look at the help for the software you are using to read & write emails to users and to groups. I find that thunderbird's interface works best for me so I have my gmail address(es) set to forward email to my ISP user address. Then I have thunderbird set to use send emails out to specific addresses and/or use different from-addresses based on where the responded-to email came from. In all of these cases, though they take a while to get used to -- and you have to keep up with changes in your software. I don't know, but I don't think cygwin is hosted as a google group, in which case, at the bottom of each email are directions for help and questions specific to cygwin: Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ Good luck! -Linda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: (getting correct DPI from windows for) cygwinX xwin resolution
Eliot Moss wrote:
As I mentioned, it is clear the XWin itself
has a notion of resolution, but most applications
do not seem to be coded to take it into account.
The main ones that I use don't, anyway, and so
I needed to adjust things in my .Xdefaults, as
I described and gave examples of in my previous
posting ...
---
Xwin has had the notion of "dpi" in it since before windows
was created. Windows programming took people backwards, in
that it specified sizes in pixels.
The new HTML5 standard has artificially defined a "software pixel",
that is supposed to be 1/96th of an inch -- independent of the
rendering device, but in HTML4, pixels were still pixels.
One way that can help on XWindows The fonts were The fixed width fonts
(100dpi/75dpi) are created to work
under those resolutions only. If the programs you are using use
Truetype fonts those should resize automatically if you
start the Xwin server using the "-dpi" switch and give it the value
for your screen -- it doesn't support multiple dpi-values for different
screen types though (neither does windows, AFAIK).
A shell script way to get windows DPI:
#!/bin/bash -u
shopt -s expand_aliases
alias my=declare
alias int=my\ -i
ord () {
printf "%d\n" "'$1"
}
get_dpi () {
my mskey='/proc/registry64/HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft'
my dpi_k='Windows NT/CurrentVersion/FontDPI/LogPixels'
read val<"$mskey/$dpi_k"
int dpi=$(ord "$val")
# check for insane values
((dpi<50||dpi>>400)) && dpi=96
echo "$dpi"
}
My check for 'insane' values may be out of date in the not so
distant future. Adjust as necessary, if your screens are really
out of this range, and set a default to something near your screen's
listed resolution. To get that use your screen's listed size
in inches. Example: using a 20 inch screen, and your display's
listed resolution from:
"Control Panel\All Control Panel Items\Display\Screen Resolution",
(you said 3200x1800 a 16:9 ratio),
calculate the following: (example in shell+perl)
(or use a calculator).
X=3200 Y=1800 #or whatever your screen size is in dots
let Z="$X*$X+$Y*$Y"; echo $Z
perl -e 'printf "%d\n", 1348**.5'
3671
above is diagonal dots. to get DPI in shell
(using the 20" screensize):
S=20
let actual_dpi="(3671+$S-1)/$S"; echo $actual_dpi
184
(so use 184 for Windows DPI, and X "-dpi").
NOTE: if you let windows resize your entire screen, instead of
just the text, then magnification is already applied to your X
display, so use "-dpi 100"
(or more precisely, "-dpi $[100*184/96]").
Hope this helps and isn't too confusing...
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: man incredibly slow because it scans for share directory in PATH??
Achim Gratz wrote:
with the POSIX shells you shouldn't have a MANPATH variable set at all
unless you did that yourself in one of your configuration files.
---
Not exactly sure where it came from (looks like an older
version of some cygwin package) but my /etc/profile sets MANPATH
and there are comments in /etc/skel/.bash_profile (and
/etc/defaults/etc/skel/.bash_profile). I see a ".orig" (my vim-
set extension for files I edit - I added some unrelated debug
stuff that came from my linux system).
The comments in the skel files, FYI, say:
# Set MANPATH so it includes users' private man if it exists
# if [ -d "${HOME}/man" ]; then
# MANPATH="${HOME}/man:${MANPATH}"
# fi
In /etc/profile I see [condensed from original version]:
# base-files version 3.9-3
# WARNING -- IF THIS FILE IS MODIFIED IT WILL NOT BE UPDATED
# BY THE CYGWIN SETUP PROGRAM. IT BECOMES YOUR RESPONSIBILITY.
# The latest version as installed by the Cygwin Setup program can
# always be found at /etc/defaults/etc/profile
# Some resources... [...]
# Setup some default paths. Note that this order will allow user
# installed software to override 'system' software settings.
# If you wish to change the path for all users, it is recommended you edit
# /etc/bash.bashrc
# If you wish all future users to have some default setup, it is recommended
# you edit /etc/skel/.bashrc
# If you wish to change the path on a user by user basis, it is recommended
# you edit ~/.bashrc
PATH=/usr/local/bin:/usr/bin:/bin:$PATH; export PATH
MANPATH=/usr/local/man:/usr/share/man:/usr/man:$MANPATH; export MANPATH
INFOPATH=/usr/local/info:/usr/share/info:/usr/info:$INFOPATH; export INFOPATH
[...]
-
As cygwin doesn't use "rpm" or any of the other utils that share that
format, it doesn't create any ".rpm{new,orig,save}" files that
contain contain new & old versions of config files & give some indication to
the user that a newer install had changes to the config.
The only thing that is apparent is that some version of /etc/profile
*used* to set MANPATH, but no longer, whereas on my linux box, some distros
have had something like:
MANPATH="${MANPATH:+$MANPATH:}\
`test -x /usr/bin/manpath && /usr/bin/manpath -q`"
has been added for POSIX compatible shells so that "man" can be configured
to pickup system-specific manpath values from /etc/manpath.config.
BTW, as for POSIX compatibility, before 2002, POSIX's charter
said that its recommendations were "descriptive". Its purpose
was to allow future programs to be compatible with what was
already there.
After 2001, or so, the POSIX name changed hands and the new charter
became "prescriptive" (i.e. it started issuing change requirements
that required existing SW to change if they wanted to remain
POSIX compat. These days, you need to specify what version of
POSIX (the Portable, _One_ System Interface data eXchange standard)
you are referring to, since the newer the POSIX version, the more
likely it isn't compatible with what you already have or are used
to.
I.e. it had been intended to apply to new SW being written so
that it would be compatible with what was "out there", but under
new leadership/ownership, was re-chartered to require existing
SW to make changes that were not backward compatible (thus
breaking the original POSIX's portability guarantees). So
sometime after 2000-2001, the new POSIX standard was no
longer portable to existing systems following the original
standard. :-(
-l
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: man incredibly slow because it scans for share directory in PATH??
Achim Gratz wrote: Riedel,Till (TM) writes: IMHO at least in Windows/Cygwin creating MANPATH from PATH makes no sense! (although I now get the idea what was the rationell!) Reasonably setting MANPATH should IMHO be a default... MANPATH is unset in a standard Cygwin installation since quite some time and it wasn't constructed from PATH before that change. I.e. in a console window, if you type: > echo $MANPATH What do you see? On my system, I see a rather short version that isn't exactly right as it has non-existing directories in it: /usr/local/man:/usr/share/man:/usr/man::/usr/openwin/man But since they are at the end, it doesn't much seem to matter. On a linux distro, All of the directories in MAN seem to exist and have man pages in them: /home/lindaw/share/man:/usr/local/man:/usr/local/share/man:\ /usr/share/man:/opt/kde3/share/man:/usr/man:/opt/dx/man:\ /opt/mpich/man (backslashes inserted by me for readability). According to the cywin manpage for man, man has a config file that tells it where to search in "/etc/man_db.conf". -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cp: skipping file 'file', as it was replaced while being copied
Kenneth Wolcott wrote: Hi; cp: skipping file 'file', as it was replaced while being copied I have several mounted partitions on my Windows machine (64bit Windows 7). Copying a file using cygwin cp , via mintty, from a mounted drive to a local path, I frequently get the aforementioned message. Is the partition not properly understood by Cygwin? I really dislike having to use Windows in the first place, at least Cygwin, when it works, makes it more bearable. The actual command was (line broken by backslash by me to make it more readable): cp /cygdrive/p/Engineering/Ken_Wolcott/new_Mobility_Audit_script/try1.pl \ /cygdrive/c/Documents\ and\ Settings/kwolcott/Desktop/files4trombone/. --- Does your 'cp' have any aliases or functions that get run? For example if you have a "cp -a" or "cp -au" as an alias, this can cause icky problems copying to or from a samba network drive from or to a local drive. I don't know if it is fixed in the latest tree, but I have a feeling it is not, because it's dang hard to fix. But it has to do with maintaining files that are *linked* where it updates one of the linked files, then tries to copy the other, and finds it gone or finds some different answer for the link's updating due to it already having been copied over via the earlier linked-file. This can also happen due to having 2 differently-cased versions of the same file (as windows sees them as 1 file and tries to get rid of the copy). It can be reproduced on linux with any fs that allows case-insensitivity (but may also be case preserving). Besides xfs having that for ascii since before xfs was on linux, I think some other FS's, zfs, maybe, and some planned future extensions to existing file systems. Again, don't know the status of this bug either, but it might be related to how the case-insensitivity is done in the file system implementing it. Why do you have 'documents and settings' on your PC? That went away with XP and was replaced by 'Users'. Is the local file system NTFS? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Proposed patch for web site: update most links to HTTPS
Adam Dinwoodie wrote: Secure connections historically had a high overhead, sure, but that's very rarely the case nowadays. Certainly my experince of loading the Cygwin web page is that there's no perceptible difference between the http and https versions. Adam Langley (a senior engineer at Google) wrote an article back in 2010 about how TLS is now computationally cheap[0]; it's only gotten cheaper since. Google talking about benefits of https everywhere is a bit like the government telling us that having 'banks' create the rules for how we use money is "impartial". https slows down the entire web -- you think not by much -- and that's because no one knows what the speed is like if everything that could be cleartext, was. Sure crypto speedups have been added to HW, but speedups in communications HW has speed up as well. So encryption speed has gone up 100-200%, in the past decade, but in the past decade communication speeds have gone up from 100Mb-> 10Gb @ home and ~1Mb -> 50-100Mb over the external net -- that's a 1000% speedup @ home to a 5000-1% speedup externally. That means more and more of that speed is being lost to crypto which can't keep up and be secure because it is expensive to do the computations. A different example: When I first started regular backups, I used gzip on default settings and thought my 5MB/s was 'normal'. As my network went up by 100x, I was still getting <10MB/s in backup speed. The bottleneck was the compression -- even fast compressors like lzo limit backups to less than 20-30MB/s. Compare that to uncompressed speeds: 200-400MB/s. At the very least, the Cygwin website should be using protocol- independent links, meaning users accessing the website using https aren't switched to http when they click on a link (i.e. link to "//cygwin.com/path/to/page" rather than "https://cygwin.com/...; or "http://cygwin.com/...;). But I agree with Brian: the Cygwin website should use https everywhere unless there's some good, specific reason why it's a bad idea. And "TLS is slow" hasn't been a good reason for years. --- Compared to the latency it induces over the net, and the increases in net speed, it's getting slower and slower and the penalty is getting worse by the year. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: locate and updatedb
Marco Atzeri wrote: On 11/02/2016 19:33, Byron Boulton wrote: On 2/11/2016 1:18 PM, cyg Simple wrote: On 2/11/2016 9:00 AM, Byron Boulton wrote: Does anyone here have success using `updatedb` and `locate` in cygwin? I use `locate` heavily on my Linux machines, but everytime I've tried to run `updatedb` on cygwin I've given up and killed the process because it is taking too long. --- There's a reason why on linux it is usually set to run when you are asleep. ;-) Is there something wrong with cygwin's implementation of `updatedb` making it not work at all or making it slower that on my Linux machines? Or are there others who have success using it on cygwin? But it might have to do with disk speed and memory. Laptop drives are usually among the slowest. I ran it just now (this is with MS's Home Essentials real-time protection turned on). law.Bliss/bin> time index_files.sh 670592 (process ID) old priority 0, new priority 19 44.21sec 15.06usr 28.30sys (98.09% cpu) locate / >/tmp/all wc /tmp/all 1479146 4014375 133322318 /tmp/all df . Filesystem Size Used Avail Use% Mounted on C: 949G 585G 365G 62% / So ~1.4 million files... Using the following exclusions: ---(index_files.sh) renice +19 $$ Local="/" if [[ -d /windows/sysnative/. ]]; then Local+=" /windows/sysnative/." fi Prunepaths='/.usr /proc /C /B /H /I /M /D /P /System[[:space:]]Volume[[:space:]]Information /Windows/CSC /pagefile.sys /Music /Pictures /Share /Media /home /Doc /$RECYCLE.BIN /cygdrive' /bin/updatedb --findoptions=-noleaf --localpaths="$Local" --prunepaths="$Prunepaths" --netpaths="$Net" Most of those pruned files are pruned either due to redundancy or being on a local network server... That's fairly fast vs. the MS-Home Essentials, full malware scan I run once a week that takes ~ 8-16 hours (It scans a few of my network directories,as well). Processing every file on the drive will be slow just because it's Windows. Initializing the database with updatedb will require a large amount of time. There are processes such as AntiVirus intrusion protection that might make it even slower. Hmmm, the reason the slowness is particuarly strange to me is that in place of using `locate` from my cygwin terminal, I have to use a program called "Everything Search Engine" available at www.voidtools.com. The first time I install it, it takes maybe a few minutes to index the hard drive, then every once in a while when I open the program it takes a few seconds to update the index, but in general the performance for indexing and searching the index if comparable to `updatedb` and `locate` on a Linux machine, so it's possible to do on Windows. Byron the time taken from updatedb is mainly due to the execution time of "find" on the disks. It takes ~ 70 minutes for my 500 GB of data, and likely the AV is impacting the execution. I suspect voidtools is using MS disk indexing to speed up the things for it. Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: fork issue when lauching cygwin64 process from 32bit native app on Windows 10 TH2
Rob van Eijk wrote: Op 1-12-2015 om 17:40 schreef David Macek: On 1. 12. 2015 15:01, Corinna Vinschen wrote: If that only happens w/ 64 bit Cygwin started from a 32 bit parent, then there's some foul-up in the WOW64 layer in terms of starting 64 bit processes, perhaps. Sigh, it's a rather unexpected change after it worked fine for so long :( Yup. I can confirm. Win10 has a 32-bit version? I thought MS said Win8 was the last version that would ship in a 32-bit version with their eventual intension to be getting rid of 32-bit support entirely (for reasons like it supporting various legacy design constraints that make it harder to manage(control) as an end-user-platform, for example)? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Another reason to not corrupt winnative symlinks: :currenly, they are linux-CIFS compat. Cygwin's are not.
David Macek wrote: Can you describe what purpose does your C:\proc serve? I'm not currently arguing for or against Corinna's proposal, I'm just curious. --- Notice the date on it... I created it 2-3 years ago... but it was likely to get some behavior to work the same with windows utils and linux utils. I have my cygroot set to '/' (sorta)...and paths on my linux box and windows box often resolve to the same file. Since the underlying NT OS is slash impartial, many pathnames will work w/o conversion. That's why I tried to get Corrina to support the MS-View of MS-junctions being the MS-equiv of linux Mount-points -- She's wiping out linux compatibility by turning them into the same as 'symlinkd' entries. I also had both cygwin32 and cygwin64 working on my system at the same time, with win-applications invoking the 'correct bit-wise versions and libs by using Ms's 32/64-bit 'system32' redirect, but having things like tar and rsync ovewrite your mountpoints on every install and update made it a high maintenance task. Basically my login to both machines looks very similar -- same bash setup. What was really 'cool' is mounting my win-fs near the root and having the Windows symlinks ... this is another good reason not to screw w/things... it will break linux compatibility even more... The symlinks on Windows work as unix symlinks when the share is mounted on a unix dir. So on linux, I see: l- 10 Jul 16 2013 D -> /??/UNC/Ishtar/Documents/ l- 10 Feb 28 2015 M -> /??/UNC/Bliss/Music/ l- 10 Feb 28 2015 P -> /??/UNC/Bliss/Pictures/ l- 10 Mar 28 2013 Share -> /??/UNC/Bliss/Share/ l- 10 Apr 21 2013 prog64 -> Program Files/ ===(among others)... But those links resolve on linux - I just created a dir in root named '??'.. etc. and filled out the structure... so file access on from my linux machine can resolve seemlessly. If corrina changes to a non-compatible symlink format then they won't resolve as linux symlinks under linux CIFS. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Symlink targets dereferenced when winsymlinks:native
Corinna Vinschen wrote: If it matters, the use case is `ln -sf /proc/self/fd /dev/fd`. It matters. This is a bug in Cygwin, a missing test in fact. It should never allow to create native symlinks to targets which only exist inside of Cygwin. Please don't. Why? It would be a built-in behavior difference between unix/linux symlinks and cygwin. symlink create on unix/linux doesn't look at the 'source' and create different types of links or different behaviors based on some ill-considered 'pathname filtering'. Consider that /proc/self/fd has no meaning to non-Cygwin processes at all. --- Unless you have a file-system driver, or a ".desktop.ini" in a windows created 'C:\Proc\.desktop.ini that redirects handlers for \proc to something similar. On my system, when I look at /proc/self/fd in cygwin+windows: cyg: /> ll /proc/self/fd total 0 lrwxrwxrwx 1 0 Nov 24 17:58 0 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 1 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 2 -> /dev/pty3 lrwxrwxrwx 1 0 Nov 24 17:58 3 -> /proc/21920/fd/ win: /> cmd Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\>dir \proc\self\fd /w dir \proc\self\fd /w Volume in drive C is System Disk Volume Serial Number is E889-68E4 Directory of C:\proc\self\fd [.] [..] 0 File(s) 0 bytes 2 Dir(s) 401,855,094,784 bytes free i.e. it shows a directory that is empty, and according to windows, was created over a year ago: C:\>dir |grep -i proc dir |grep -i proc 01/23/2014 05:13 PM proc As soon as you start prohibiting normal 'native' link creation based on some assumption about "who owns the path", I can't see how that won't end up biting you later. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: No support for ACLs on network shares?
Matt D. wrote: My samba server is configured to use winbind and when inspecting the file using explorer properties, the SIDs resolve correctly as: "NAME (HOSTNAME\username)" where "NAME" is my name on the unix account and "username" is my login. The problem is that Cygwin isn't aware of this SID since it's the user I log in as to the remove server and isn't a local SID. So the remote server has a different user-database than what is used for your Cygwin-on-windows machine? I.e. username seems like it is 'private' to HOSTNAME. So let's say your cygwin machine is (or is not) part of a domain. If it is, it contacts the domain server to resolve sid's to populate the local /etc/passwd database (in memory or on disk). If it isn't, it contacts the local-host's name resolution routines to do the same. If you are not logging into 'HOSTNAME' as a DOMAIN user -- it's a different user -- and how would cygwin know what the remote system has setup for it's local-user database? I.e. On a normal Winstation, users Winstation\user && Domain\user are different SID's -- **except** on the DC. So files I create as 'user' on my Samba3-DC, are owned by 'Domain\User'. If I login to my local winstation (which is part of /joined to the domain), the default login space is 'Domain\' unless you override it with a local host name -- then you get the local user. And, BTW, I still have 2 accounts on my Winstation -- one created before the winstation was part of a domain, and the other created after. Does this explain your situation, or is it something else completely? Linda P.s. - Your top-posting was pleasing, I got to read what you said 1st instead of the quoted reply, which I'd already read(people who tend to jump in, in the middle of a conversation, really don't like top-posting as it puts the onus on them to read prior posts in the thread). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Personal use not permitted: (was Re: Pop up GUI remotely via SSH)
trimat wrote: If I create the service with the command /ssh-host-config/ (and then set up user and privileges) I can start remotely from SSH a program without the possibility to see its GUI. Where are you expecting the output to come out? Where it is executing or where you ran ssh from? Windows can't do the latter, it can only do the former, and then only if you get all the security tokens setup right (never have done it). They used to have problems where people would start programs from remote machines and popup output on a remote PC, and people on the remote PC would respond to it thinking it was a local system message (when it was really a remote cracker trying to get their password). If I modify the /sshd/ service by Windows Services logging on as "Local System account" with "Allow service to interact with desktop" option enabled, I get an error: "The CYGWIN sshd service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs". --- Similar problem as above. You can't forward remote output of individual Windows programs. You could try to start a remote-desktop session -- and those have the ability to run programs on startup that will have their output go to the person who ran remote desktop, but what you seem to be asking for is like when I "ssh" into a linux box and start 'gvim', it runs 'gvim' and displays it on my local cygwin box. That is all premised on ssh automatically forwarding any attempts to access the remote X-server to your local box, where they will try to contact your local X-server. I am not aware of Xserver, how can I check this? --- Read up on 'X11' on the web/google. It is the main way unix/linux boxes run programs remotely and have the output displayed locally. If you know nothing about 'X', or how output from 'ssh' run programs is forwarded through an encrypted connection back to your machine to connect to the X-server (called Xwin.exe on cygwin), then you need to learn alot more about what you are attempting to do -- much more than I can relate in a "short" email. Windows was designed around a 1 person/computer system, with allowances for more than 1 person with the server editions of windows. If someone is logged into a windows PC (non-server edition), you cannot log into it with remote-desktop, for example, without it either blocking you (because someone is already using the "1" Windows output channel), or "2" forcing the remote user to log-out -- which can then allow you to create a 'remote desktop session' where the remote pc's desktop is forwarded to you. If you had a server and used "thin-clients" that would only be used for keyboard and display (no local processing), MS didn't want you to be able to grab the 100-cheap clients and all log into the powerful server and share applications (like all of them running their own version of WORD) -- because, instead, they wanted to sell 100-copies of Windows and 100 copies of WORD - even if only 1-5 out of 100 would use WORD at any point in time. They compromised on server editions by allowing people to by "seats", which allow a "small", fixed number of users to run an application (or to access the server remotely) -- but they keep track of each user who uses a 'remote desktop', and accesses a program like WORD, to make sure you only can use the number of "remote sessions" you paid for. If you want a multi-user computer, you need to run linux or something else. But both apple and MS have gone with the 1-user-1-licence model. The recent push to convert linux to use systemd -- is all about reducing the functionality of linux to require the same thing -- so 1 system monitor (systemd) can keep track of how many users are using "licensed seats" --- so vendors can force you to pay 10-100 times for the same program. It's also about locking down linux so that you can't easily your own programs to get around such licensing mechanisms (you'd have to "jailbreak" your computer -- as is done with smartphones these days, to allow you to run what you want on your own computer). If you want the remote display thing, use 'X' while it is still available and not replaced by some encrypted-proprietary (but open source) replacement that restrict what you can do on your computer (effectively reducing it to a "console" -- as in gaming console that only runs the programs that the manufacturer permits). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Using cp converts windows junctions to a cywin symlink; a security-config override
Andrey Repin wrote: Greetings, Adrian H! > I was copying a directory of files, some of which were windows junctions. > These got converted to a cygwin symlink. Although I am impressed that there > are such a thing for those OSs/drives that do not support such things, for those > that do, I think it would be good to keep the copy a junction. Otherwise, > things can get messy. > Can this be corrected? --- (BTW -- you do know about the 'winsymlinks:native' setting in the CYGWIN environment variable? It might be of some use.) Andrey wrote: Unfortunately, even on systems, that do support symlinks functionality, it is restricted by UAC and not easily unlocked. --- Actually that's control by Windows group policy. It's alot like whether not 'users' can control 'mounts' on linux. It can be allowed, but doing so categorically might not be considered wise. You'd need an admin shell or a user profile with UAC turned off and permissions correctly configured to exploit native symlinks. --- Or the system administrator would have to enable user-control of local symlinks. The ability to allow users to create and use symlinks is control through 4 settings: fsutil behavior query SymlinkEvaluation * Local to local symbolic links are enabled. * Local to remote symbolic links are enabled. * Remote to local symbolic links are enabled. * Remote to remote symbolic links are enabled. --- On my windows machine, unprivileged users are able to create all 4 types of symbolic links. As for junctions and mountvols -- they require the same privileges on windows as they do on linux. I.e. a normal user can't mount or graft portions of the file system other places -- mount is normally restricted to root-only. Having cygwin destroy/overwrite linux-comparable 'mounts' would be and should be considered a serious security bug. If I mount a linux dir at another location -- imagine if 'cp' changed those mount point to symbolic links (which no longer work consistently or the same on linux as they use to, as some security-spazes came up with the idea that being able to create a symlink (not hardlink) to a file you don't own, was considered a security risk -- even though in reality symlinks are safer than hardlinks in such cases, because the symlinks have to traverse the intervening directories and security checks. On windows, the "allow traversing paths you don't have access to" is a privilege that has been used to allow users access to area they didn't normally have access to. However, on linux there never was such a privilege, so the added the ability to mount normally "private" areas in other places -- going around the intermediate path-walk-security checks. Now with the mount option, the default on most distros is to disable creating symlinks to files you don't own -- which doesn't serve the same purpose -- since such symlinks STILL follow all the intervening security checks at each directory. Note--disabling the windows privilege to bypass traversed directory security checks would achieve the same effect on windows as it does on linux, but MS strongly advises against doing this, as so much software makes use of this feature and assumes it is in place (it is the default). To find out more about the linux google on /proc/sys/fs/protected_hardlinks & /proc/sys/fs/protected_symlinks And Cygwin does not support creation of directory junctions to the best of my knowledge. :( --- Neither does linux support creation of user-controlled mounts. Not have cygwin destroy "volume mount points" that are a parallel to linux's ability to mount any directory anywhere else, would be very useful. Destroying the mountpoints as it does now, is a hacker's dream, as they can destroy a local admin's mounting of a read-only dir there and allow potentially virus laden programs to replace them. Nice. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Mounting a network share
Andrey Repin wrote: Greetings, Mike Brown! I'm remotely loggin in to my P box and would lke to mount one of the NAS Samba shares. M$ likes to unmount the share after a period of time, but because it was mounted, the pasword is needed (I hope). When I try the following: mount \\192.168.1.40\Public /cygdrive/p --- Got to watch out for the those backslashes: This seems to work: mount //ishtar/tmp /tmp/tmnt mount: defaulting to 'notexec' mount option for speed since native path references a remote share. Use '-f' option to override. /tmp> df /tmp/tmnt Filesystem Size Used Avail Use% Mounted on //ishtar/tmp 12G 8.4G 3.7G 70% /tmp/tmnt Though I'd likely use 'net use' as others mentioned. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Pop up GUI remotely via SSH
trimat wrote: Hi all, I would like to pup up on Windows 7 the GUI of a program started remotely from SSH. I can't obtain this with *cygstart* even though I see the process running in Windows Task Manager. Trying to add /--interactive/ flag to Cygwin service /sshd/, the service doesn't start. Am unclear here. Where are you starting ssh from and where is sshd running? Are you trying - say, when you login to windows, 1st have it run the Xserver, then have a 2nd program run ssh to a remote (linux? Windows?) machine, where it starts an X-GUI, on the remote (linux? cygwin on windows?) that display back on the machine you just logged into? Are you are you have the Xserver running locally before you run the ssh command? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problems w/cygsym links vs. winsymlnks: (was Re: Running a program using a DLL under Cygwin)
Andrey Repin wrote:
Greetings, Linda Walsh!
I think symlink is a cygwin thing. Windows won't find that DLL (just
like you won't find it using windows explorer.)
Unless he have created a Windows symlink, that is correct.
Explorer, however, may find it, as Cygwin symlinks are Windows LNK files.
Cygwin symlinks can use native Windows format, if you put 'winsymlinks:native
export'
in your 'CYGWIN' env var at startup -- preferably in your Win profile.
However, cygwin occasionally has some bugs in how it creates links:
/tmp> touch x
/tmp> ln -s x y
/tmp> ll x y
-rw-rw-r--+ 1 0 Oct 10 22:27 x
lrwxrwxrwx 1 6 Oct 10 22:28 y -> /tmp/x
/tmp> cmd /c dir ?|grep '\s[xy]'
10/10/2015 10:32 PM 0 x
10/10/2015 10:40 PM y [C:\tmp\x]
/tmp> rm y
/tmp> mklink x y
Do note that native mklink has arguments in the opposite order. (Microsoft...)
---
Yes... but notice I typed that at a bash prompt and that
it did the same thing as 'ln -s' and worked with the same order
(mklink = bash-script that wraps around native mklink to make
it same order). This also has mklink working but 'ln -s'
changing a relative link to a absolute link
Another example of cygwin's 'ln -s' chainging the link:
---
/tmp> mkdir foo
/tmp> ln -s foo cygfoo
/tmp> mklink foo winfoo
symbolic link created for winfoo <<===>> foo
/tmp> cmd /c dir|grep foo
10/11/2015 11:23 AM cygfoo [C:\tmp\foo]
10/11/2015 11:22 AM foo
10/11/2015 11:24 AM winfoo [foo]
---
looks innocent enough until I mv them:
/tmp> mkdir links
/tmp> mv foo cygfoo winfoo links
/tmp> cd links
/tmp/links> ls
cygfoo@ foo/ winfoo@
/tmp/links> ll
total 0
lrwxrwxrwx 1 8 Oct 11 11:23 cygfoo -> /tmp/foo
drwxrwxr-x+ 1 0 Oct 11 11:22 foo/
lrwxrwxrwx 1 3 Oct 11 11:24 winfoo -> foo/
-
Notice the cygwin created symlink points to a
non-existing file /tmp/foo.
A 3rd problem is trying to create the links
before creating the dir.
Not a problem on linux, but on windows, notice above, the
symlinks to directories are a different type
than the ones to regular files.
So, currently the shell wrapper complains, but cygwin
creates a cygwin-only symlink: a hidden 'System' file that
windows can't use and normally doesn't see:
/tmp/links> ln -s foo2 cygfoo2
/tmp/links> mklink foo2 winfoo2
Source, "foo2", does not exist.
### uhoh, "forgot" to create foo2 1st, better create it now:
/tmp/links> mkdir foo2
/tmp/links> mklink foo2 winfoo2
/tmp/links> ls *?foo2
cygfoo2@ winfoo2@
/tmp/links> ll *?foo2
lrwxrwxrwx 1 4 Oct 11 12:31 cygfoo2 -> foo2/
lrwxrwxrwx 1 4 Oct 11 12:37 winfoo2 -> foo2/
### create files in cygfoo2 and winfoo2 from cygwin:
/tmp/links> touch {cyg,win}foo2/child_file
/tmp/links> ll {cyg,win}foo2/child_file
-rw-rw-r-- 1 0 Oct 11 13:22 cygfoo2/child_file
-rw-rw-r-- 1 0 Oct 11 13:22 winfoo2/child_file
## so cygwin can create a child_file in each, but
## win's dir /a?
### looks like cygfoo2 is there, as seen on cygwin, above, but a
### dir cmd from win doesn't see it:
/tmp/links> cmd /c dir|grep ' [AP]M'
10/11/2015 12:37 PM .
10/11/2015 12:37 PM ..
10/11/2015 11:23 AM cygfoo [C:\tmp\foo]
10/11/2015 11:22 AM foo
10/11/2015 12:35 PM foo2
10/11/2015 11:24 AM winfoo [foo]
10/11/2015 12:37 PM winfoo2 [foo2]
### attrib/no args shows files with attrs set:
/tmp/links> attrib
S C:\tmp\links\cygfoo2
### dir /a will show also reveal hidden and system files:
### this shows diff of cygwin ln -s foo2 cygfoo2
### and the bash-shell wrapper calling mklink
### (after 'mkdir foo2')
/tmp/links> cmd /c dir /a *?foo2|grep ' [AP]M'
10/11/2015 12:31 PM22 cygfoo2
10/11/2015 12:37 PM winfoo2 [foo2]
## creating files in 'cygfoo2 and winfoo2
For the purposes of DLL loading, hardlink is probably a good choice.
---
There is one drawback to hardlink usage (if softlink usage doesn't
matter, of course, that's irrelevant). All copies of a hardlinked
file will be locked if any of them are.
Vs. if you use softlinks, -- the file they point to will
likely be locked, by the symlinks might not be... if that's
the case, symlinks could be repointed at new "dll"'s for
fixes without requiring requiring the current dll's not
be in use.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Running a program using a DLL under Cygwin
Andrey Repin wrote: Greetings, Yucong Sun! https://cygwin.com/acronyms/#TOFU pretty please... I think symlink is a cygwin thing. Windows won't find that DLL (just like you won't find it using windows explorer.) Unless he have created a Windows symlink, that is correct. Explorer, however, may find it, as Cygwin symlinks are Windows LNK files. Cygwin symlinks can use native Windows format, if you put 'winsymlinks:native export' in your 'CYGWIN' env var at startup -- preferably in your Win profile. However, cygwin occasionally has some bugs in how it creates links: /tmp> touch x /tmp> ln -s x y /tmp> ll x y -rw-rw-r--+ 1 0 Oct 10 22:27 x lrwxrwxrwx 1 6 Oct 10 22:28 y -> /tmp/x /tmp> cmd /c dir ?|grep '\s[xy]' 10/10/2015 10:32 PM 0 x 10/10/2015 10:40 PM y [C:\tmp\x] /tmp> rm y /tmp> mklink x y symbolic link created for y <<===>> x tmp> cmd /c dir ?|grep '\s[xy]' 10/10/2015 10:32 PM 0 x 10/10/2015 10:43 PM y [x] Normally cygwin can create relative symlinks but for some reason using these names -- in /tmp, it did not. (if I used a name other than 'y' for the symlink like 'winlink' or 'cyglink' then they both were relative links) Go figger... Also, FWIW Cygwin 'hardlinks' are Windows 'hardlinks'. No significant difference. So you could use a windows symlink or hardlink created in cygwin to the location of your 'dll' and it "should" work (but I haven't tested it) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: strange cygwin sshd user generated (user name includes machine name)
Peter Moore wrote: Hi, I have a powershell script for installing cygwin and setting up sshd which I am using as UserData when firing up a Windows 2012 R2 instance in AWS EC2. The same command succeeds when run manually, but fails when called from automation. I’m trying to understand what it is that is different, so I can fix it in automation. I have both a domain account (Bliss) and a local account on my winclient(Athenae): Bliss\linda & linda Using Domain account on client -> Domain server ssh Bliss server logs say: ... sshd[49322]: pam_winbind(sshd:account): user 'Bliss\linda' granted access using ssh linda@Bliss, server logs say: sshd[51179]: pam_winbind(sshd:account): user 'linda' granted access Using local account on client ->Domain: ssh Bliss server says: Oct 9 20:51:21 Ishtar sshd[51787]: pam_winbind(sshd:account): user 'linda' granted access if I want to login to the domain account, I need to specify it as the user: ssh 'Bliss\linda'@Bliss server says: sshd[51982]: pam_winbind(sshd:account): user 'Bliss\linda' granted access so in the above case, I am seeing a similar "symptom" -- where it uses 'domain\user' when I'm logged in my domain account and just 'user' if I specify 'user@Domain'. Both login to the *same* account on the PDC -- because on the PDC local users are domain users -- because the SID of the local machine is the same as the domain SID. I.e. on the domain server, I can display the domain or the local machine SID: net getlocalsid #note, it equates local machine name as a domain name in this case SID for domain ISHTAR is: S-1-5-21-3-7-3 When I ask for the domain sid: it displays both: net getdomainsid SID for local machine ISHTAR is: S-1-5-21-3-7-3 SID for domain BLISS is: S-1-5-21-3-7-3 So first, obvious question is "are domains involved", but 2nd question ... are the machine 'SIDS' the same in both cases? I.e. when you run 'live' vs. run under automation, maybe the 'automation' looks like a different machine name and uses a different 'sid'? That'd be my best guess...I only replied because I have seen the same symptom depending on usage of the domain vs. local account. Good luck! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin potentially corrupting permissions?
Andrey Repin wrote: @Greg Freemyer: An "army in the world" does not have passwords and firewalls. That's the only reason they are trying to rely on obscurity. Doesn't quite work, as attacker could just carpet bomb the target positions. --- password = obscure secret; crypto = hidden secrets that take time to find. Both are a form of obscurity. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin potentially corrupting permissions?
Greg Freemyer wrote: Totally logical, but not accurate. ) --- What does it say if you do an 'lsacl' on "." (the parent directory). This is a local file system? NTFS? Do you have process hacker? Maybe the writing process has a different integrity label or such. Process hacker lets you see what the integrity labels are on files, but to see what they are on files you'd have to d/l another util. (chml/regil - cygwin is not properly maintaining the permissions when it manipulates a file May not be able to ... Windows trumps cygwin. MS-regularly screws w/windows, .. it's like switching to a new init system every month... ok.. maybe not quite that bad... Either way, I would really like a solution that doesn't involve a manual chmod for every file I create via the normal Windows interface and which I want to work with it in cygwin. === I can understand that -- that's sorta why I haven't upgraded my cygwin lately -- She spent alot of time solving a problem that didn't really appear on my system, so changing the whole security system -- well I already know that cygwin doesn't respect existing standards or sources. (overwrite windows mount points created -- and is shipping a login that zeros your environment -- even when passed switch to not do so -- effectively wipes your windows session -- forcing users to copy sessions from static files to get around the problem. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin potentially corrupting permissions?
Andrey Repin wrote: Your system seems to be mangled. There should be no "root" user. Also, please avoid top posting as per list rules. You are missing one? Don't tell me, you have Administrator instead? Maybe that's why you see Greg's messages as top-posted, where as I saw him as interleaving his response w/what I said? ;-) If you have Win7-Pro or above, you can rename Admin and Guest accounts -- which is recommended for security reasons. If you read windows 'rules', you'd know that... (so many rules to read...really hard for someone to keep up)... *cheers* -l -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin potentially corrupting permissions?
Andrey Repin wrote: Obscurity has no relation to security. Oh, and these both are disabled on my systems. If you read windows 'rules', you'd know that... (so many rules to read...really hard for someone to keep up)... There's no such rules as "rename default accounts". It makes no sense and bears no reason. --- Security best practices : See "https://technet.microsoft.com/en-us/library/cc747353%28v=ws.10%29.aspx; and "https://technet.microsoft.com/en-us/library/jj852273.aspx; -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin potentially corrupting permissions?
Greg Freemyer wrote: On Thu, Sep 24, 2015 at 3:27 PM, Linda Walsh <cyg...@tlinx.org> wrote: Greg Freemyer wrote: Totally logical, but not accurate. ) --- What does it say if you do an 'lsacl' on "." (the parent directory). $ ./lsacl.sh . [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] . But maybe this is interesting. I just created 2 folders in C:\ . I did it at the C:\ level because I can't imagine I ever modified the ACLs on C:\. Anyway, one directory was created via "mkdir" in cygwin. The other via the file explorer. Look at how different the ACLs are: $ mkdir /cygdrive/c/Test-dir-created-in-cygwin $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-cygwin/ [u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x/u::rwx,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:r-x] /cygdrive/c/Test-dir-created-in-cygwin/ $ ./lsacl.sh /cygdrive/c/Test-dir-created-in-file-explorer/ [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---] /cygdrive/c/Test-dir-created-in-file-explorer/ What's that about? Again I'm not expert at ACLs, but the ACLs on the directory created via File Explorer look really strange to me. - That looks like the 'Creator User & Creator Group Policies at work, which try to let you create a dir in root, but give limited access to that dir -- but doesn't allow just any Creator to have full access... I think you are seeing a trickle down effect from the creator owner policy and the creator group policy banning full access -- because if you look at the security tab in explorer I'll be those are pretty restricted... This is a local file system? NTFS? Yes, C: drive. It's my local system drive on both computers and NTFS on both machines. Do you have process hacker? Maybe the writing process has a different integrity label or such. Look at the acl in the Explorer 'security tab' You find some extra rules for 'creators' that are supposed to allow them to do things inside the dir but not to the dir or some such. No, but let me know if you still want me to pursue that. For now I'm thinking the ACLs on folders created via File Explorer are somehow getting screwed up. 'screwed-up' is relative -- i.e. in this case, likely what explorer is designed to do, (screw you), *str8-face*... In the home directory you want to deal with this in (I wouldn't suggest changing drives from root folder (I do such things and constantly end up with 'shot-in-foot' type problems that I get to have 'fun' fixing! ;->) But get rid of the creator rules so they won't propagate have to do it from windows those because those entities aren't posix. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues encountered with new Cygwin version
Walter L. wrote: > > > > I believe the target of the symlink should be "protocol" (i.e. How would that affect 'services'? Sorry, you lost me. 'services' has 8 characters in the file name and so is its symlink target; That shouldn't be an issue. Of the 4 symlinks under /etc/ (i.e. networks, hosts, services, and protocols), only 'protocols' exceeds the 8 character limit and hence the actual target file in Windows/System32/drivers/etc/ is 'protocol'. NOTE: I'm talking about the *target* file not the symlinks themselves, which are fine. --- Oops.. my bad -- don't know why I substituted services. However, weren't those files there for unix-subsystem support? Not sure: From this: https://books.google.com/books?id=6hlNFc7drzEC=PA39=PA39=reason+for+drivers/etc/protocol+on+windows=bl=en=X=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false#v=snippet=reason%20for%20drivers%2Fetc%2Fprotocol%20on%20windows=false (page 39) -- it says those files were specific to NT systems beginning with NT4.0, which used NTFS. I don't know if NT supported having the windows/system32 directory on FAT][32]... NT4 would have been the version before Windows 2000 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin potentially corrupting permissions?
Greg Freemyer wrote: Linda, I saved your script as "lsacl.txt". Then I used "cp lsacl.txt it" to make a copy. The copy is permission denied for reading. Basic ls -l shows no difference (as expected) $ ls -l lsacl.sh it rwx---+ 1 gaf None 1630 Sep 24 12:05 it rwx---+ 1 gaf None 1630 Sep 24 12:00 lsacl.sh But your script does show a difference: $ ./lsacl.sh lsacl.sh it [u::---,g::---,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] lsacl.sh [u::---,g::r-x,g:root:rwx,g:Authenticated Users:rwx,g:SYSTEM:rwx,g:Users:r-x,m:rwx,o:---/] it --- Well user 'gaf' (that's you, from the file perms has no access). So up front, you are denied before anything happens. lsacl is the embedded acl (the '+') at the end of the file perms u::--- = user seen by 'ls -l' has no access, g::--- = group seen by 'ls -l has no access g:root:rwx = group root has read/write/execute access g:Authenticated Users:rwx == group consisting of Authenticated Users... (after you login or provide credentials). m:rwx m = a maximum allowed privs 'mask' for user/groups other than owner, but since all bits are turned on, it has no limiting effect o:--- = other has no access So the main take-away is that since your 'user' has no access, pretty much everything else is ignored. From the mode-bits+acl, amost anyone in the groups: root, Authenticated Users,SYSTEM, or Users, ***except** User 'gaf' (you) should have access... you might try 1) chmod u+rwx file ... then look at both mode+acl... if you have no access and acl still says u::---, then nuke the acl or modify it with "setfacl" (setfacl --help)... We seem to travel the same mailing lists. This is my first time to cygwin's. Yeah... I wondered about that -- my Tbird tried to change my reply addr to suse(at)tlinx based on you being the 1st address I typed in... ;-) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues encountered with new Cygwin version
Andrey Repin wrote: I believe the target of the symlink should be "protocol" (i.e. singular) Err. That is. How did no one found it earlier? --- Because it is plural on unix/linux? MS seems to have misspelt it? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues encountered with new Cygwin version
Walter L. wrote: Define "earlier" ? The permissions handling has been extensively rewritten since 1.7.34. Probably from a few months ago, but I can't confirm. I've been trying to figure out how to revert back to an earlier version to verify this. Where can I find archived versions of Cygwin? --- Yeah... I hear that... am more than a little afraid to update my cygwin to 2.x for fear of some icky breakage...(i.e. my groups/users, mostly work using my Linux server as a NT4-level domain server/file server. Am afraid new security will in some way break things... Already -- cygwin has broken NT-mount points created with linkd and ship a broken version of 'login' that doesn't honor the "-p" switch resulting in the need for insecure workarounds. Will likely upgrade at some point, but am not looking forward to it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin potentially corrupting permissions?
Greg Freemyer wrote:
All,
I've noticed on 2 different machines that if I copy (cp) a file I can
read with cygwin, I don't have permission to read the copy.
---
What does the acl say?
(Attached a script, lsacl, that I use -- it works
with linux or cygwin and allows wildcards).
#!/bin/bash
## $Id: lsacl,v 1.5 2015-08-02 10:29:25-07 law Exp law $
# Version 2 -- try to work with getfacl on cygwin
#
shopt -s expand_aliases
alias int=declare\ -i sub=function string=declare
gfacl=$(type -P getfacl)
if ! type -f cygwin 2>/dev/null ; then
_un_=$(type -P uname)
if [[ $_un_ ]] ; then _os_=$($_un_ -o);
elif[[ -e /proc/sys/kernel ]]; then _os_=Linux;
else_os_=Cygwin;
fi
if [[ $_os_ =~ Cygwin ]]; then function cygwin () { return
0; }
elsefunction cygwin () { return 1; }
fi
unset _un_ _os_
export -f cygwin
fi
if cygwin 2>/dev/null ;then
[[ $gfacl ]] || { printf "FATAL: Cannot find getfacl in path\n"; exit
1; }
sub gfacl () { "$gfacl" "$@"; }
else
## linux version has broken semantics requiring "-p"
sub gfacl () { "$gfacl" -p "$@" ; }
fi
export -f gfacl
sub facl2str {
string fn=${1:?"Need pathname"}
string s1='/^\#.*$/d; /^\s*$/d; s/\s*#.*$//;
s/^(.)(ser|roup|ask|ther):/\1:/; y/\n/,/'
string facl=$(gfacl -a "$fn"|sed -r "$s1"|tr "\n" ",")
facl=${facl%,}
string dacl=$(gfacl -d "$fn"|sed -r "s/^default://; $s1"|tr "\n" ",")
dacl=${dacl%,}
printf "[%s/%s]\n" "$facl" "$dacl"
}
int acllen=0 maxfnln=0
#for fn in "$@" ; do if ((maxfnln<${#fn})); then maxfnln=${#fn}; fi ; done
sub acl_str () {
if cygwin ;then
perm=$(facl2str "$fn")
else
qfn=$(printf "%q " "$fn")
out="$(chacl -l "$fn")"
perm="${out#$qfn}"
fi
printf "%s\n" "$perm"
}
for fn in "$@"; do
int max=40
perm=$(acl_str "$fn")
int len=${#perm}
if ((len>_acl_len_)); then acllen=len; fi
if ((acllen>max)); then acllen=max; fi
printf "%-${acllen}s %s\n" "$perm" "$fn"
done
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ssh fails after joining domain
Hoot Thompson wrote: I'm working on a group of Windows Server 2012 R2 systems. Prior to joining the systems to our domain controller, I install the openssh components after which I can ssh into the system using the Administrator account and password. However, as soon as I join a server to our domain controller, ssh no longer works for the exact same Administrator account. Are local accounts (such as the aforementioned Administrator account) blocked somehow after joining the domain? Is there someway I can make the local account work again? Where does cygwin come in? Is it a server, or are you trying to login using cygwin's ssh? Assuming the latter is the case, as soon as you join a system to the domain, the default domain, I believe becomes (not the previous local hostname). So you might try: 1) logging in as 'DOMAIN\Administrator' (if you have that password), or 2) logging in as '\Administrator' Note the single quotes around the login name *should* be used if you are logging in from a cygwin shell (like bash). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Issues encountered with new Cygwin version
Walter L. wrote: > > I believe the target of the symlink should be "protocol" (i.e. > > singular) > > Err. That is. How did no one found it earlier? --- Because it is plural on unix/linux? MS seems to have misspelt it? I believe it's "misspelt" due to the 8 character limit for legacy file names, --- How would that affect 'services'? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fish Shell Speed?
David Frascone wrote: 1) Has anyone seen this behavior before? If so, do you remember which functions may be causing it (hg vs git speed under cygwin maybe?) 2) Any thoughts on trying to profile a prompt and/or shell script, if I pull it out of the prompt function Anytime you have to call an external process, you pay a multiplied penalty on cygwin -- 1st linux process spawning, while costly, are less than Windows, and 2) cygwin has to emulate the posix semantics on windows -- to which it is not friendly. If you could somehow cache recent data in data struct and only updated ever 10 minutes with a live call, that might help...? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mkpasswd: option to force the 'primary' domain?
Corinna Vinschen wrote: On Mar 20 11:58, Tim Magee wrote: Now then, Since Cygwin 1.7.34 dropped, mkpasswd has been problematic for us. Our problem is with the way user names pulled from outside the primary domain get decorated. My question is: will there ever be a way to tell mkpasswd/mkgroup make some non-primary domain the one whose users get undecorated names? I'm not planning this. The idea is that mkpasswd/mkgroup create account names compatible with the db-based accounts and everyhing else is left to post-creation manipulation. --- I never quite managed to understand this -- as my pw/grp files on my client machines were already in sync with my domain setup and worked as it would in a real Win Domain (i.e. Domain applied when I signed into a machine that wasn't the domain controller and was using domain credentials). If I logged into a machine with a local account, there has never been a domain name to have to bother with -- so for me user-logins were prefixed with the domain only when they were in a domain. This has been the way windows has worked for as long as I've run a domain server -- if a local machine is not in a domain, then it's username-only, but if it is in a domain, then I'd need to type-or-add the local-machine name to NOT login via the domain creds. For local accounts, the RID==the UID, for domain accounts the RID==the UID on the domain controller. Do I understand that cygwin is no longer compatible with window's (and samba's) naming convention? That would be a pain. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty startup message: /sbin/nologin: No such file or directory
Corinna Vinschen wrote: As for /sbin/nologin itself, I'm not sure why I did that without providing an /sbin/nologin executable. This is very clearly an oversight on my part. In theory it should be part of the util-linux package, but it isn't for some reason. Yaakov, any idea why? Is it a problem to add it? --- This works on a linux machine: uuencode /bin/nologin /bin/nologin begin 664 /bin/nologin M(R$O8FEN+V)AV@*96-H;R!4:ES(%C8V]U;G0@:7,@8W5RF5N=QY(YO 5=!A=F%I;%B;4NF5X:70@,0H* ` end --- (FYI: cat /bin/nologin: #!/bin/sh echo This account is currently not available. exit 1 --- A binary version is listed as being in util-linux-2.23.2, FWIW. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.35 reads file permissions differently, affects broken apps
Corinna Vinschen wrote: cygwin-1.7.32 $ ls -l -rwx--+ 1 LocalService Domänen-Benutzer1932 15. Aug 2014 fetchmailrc.txt cygwin-1.7.35 $ ls -l -rwxrwx---+ 1 LocalService Domänen-Benutzer1932 15. Aug 2014 fetchmailrc.txt Now, there are group permissions set. For me it breaks fetchmail, because fetchmail only runs when the config file is owned by the user running fetchmail (LocalService in my case, a system user I never can login with) and with max 0700 permissions. --- I can confirm this bug exists in linux and is also present in other mis-designed apps. It's not cygwin specific. Ishtar:law llg .fetchmailrc -rwx-- 1 law lawgroup 1103 Dec 14 13:49 .fetchmailrc* Ishtar:law chmod g+rw .fetchmailrc fetchmail File /home/law/.fetchmailrc must have no more than -rwx-- (0700) permissions. sudo fetchmail fetchmail: WARNING: Running as root is discouraged. File /home/law/.fetchmailrc must have no more than -rwx-- (0700) permissions. Another example: sudo lilo Warning: /etc/lilo.conf should be writable only for root Added 3185-Isht-Van Added 3173-Isht-Van * One warning was issued. Ishtar:linux/ish-3192 llg /etc/lilo.conf -rw-rw-r-- 1 root root 3589 Mar 17 19:48 /etc/lilo.conf ssh[d](re .ssh) , sudo (re sudoers), and I believe you thought ~/.rlogin also have this problem. It is a growing problem for those of us who manage security by group perms (I setup my linux box with 1 group per user several years ago to allow for Windows-security compatibility). For a while I was able to get around the problem with ACL's, but these days, more apps are becoming ACL-aware. Maybe linux needs a new Discretionary-access security module, dup'ed off the current model, but with an extra set of dummy file permissions that can be configured to be returned when run under a specified list of program names. Hmmm...I like it! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rsync still broken
Frank Fesevur wrote: ... I use --numeric-ids and I have these two lines in the rsyncd.conf uid = 0 gid = 0 --- How is your local rsync talking to the server? I.e. using the 'rsyncd' daemon running on the server? For me, I don't have the rsyncd daemon running full time on the server, but use the remote shell option with my RSYNC_RSH environment var set to 'ssh'. Just reading on the man page that this is the default on most systems these days. If you use the rsyncd daemon, you should read the rsyncd.conf manpage: Especially this section: uidThis parameter specifies the user name or user ID ... The default when run by a super-user is to switch to the system’s nobody user. The default for a non-super-user is to not try to change the user. See also the gid parameter. --- It doesn't look like uid and gid set to 0 will just work. If you use the 'ssh' protocol for transfers, you would need to be able to login from your local system to the server as 'root' with no password: i.e.: ssh root@server If that doesn't work -- rsync probably won't work correctly either. But the thing that surpises me is that in 3.0.9 is just worked. --- I'm still at 3.0.9 and don't want to break things, but you are right: --- law.Bliss whoami Bliss\law law.Bliss mkdir cygwin law.Bliss mkdir /h/cygwin ## /h=homedir on server law.Bliss llg -a /h/cygwin total 0 drwxrwxr-x+ 1 Bliss\law lawgroup 0 Mar 19 17:07 ./ drwxr-xr-x+ 1 Bliss\law lawgroup 0 Mar 17 20:36 ../ law.Bliss echo test cygwin/test.txt law.Bliss rsync -a cygwin/. ishtar:cygwin/. law.Bliss llg -a /h/cygwin total 4 drwxrwxr-x+ 1 Bliss\law lawgroup 0 Mar 19 16:42 ./ drwxr-xr-x+ 1 Bliss\law lawgroup 0 Mar 17 20:36 ../ -rw-rw-r-- 1 Bliss\law lawgroup 5 Mar 19 16:42 test.txt law.Bliss rsync -v rsync version 3.0.9 protocol version 30 Yup -- seems to work in 3.0.9. BTW -- rsync is pretty slow for some transfers -- created a 1G local file and timed transfers with rsync, cp and dd. with 'dd' I used direct which should be synchronous/unbuffered, but I don't think rsync or cp have options to turn that off. Still 'dd' was fastest, followed by 'cp' and rsync, well: law.Bliss dd if=/dev/zero of=1G bs=1M count=1024 oflag=direct 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 1.96472 s, 547 MB/s #local file law.Bliss time rsync 1G ishtar:cygwin/ 18.76sec 3.43usr 2.40sys (31.07% cpu) #using rsync proto law.Bliss rm /h/cygwin/1G law.Bliss time cp 1G /h/cygwin 8.53sec 0.00usr 0.77sys (9.13% cpu) #cp using SMB/CIFS law.Bliss rm /h/cygwin/1G law.Bliss time dd if=1G of=/h/cygwin/1G bs=1M count=1024 oflag=direct 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 6.91213 s, 155 MB/s # dd using SMB/CIFS 6.95sec 0.01usr 0.67sys (9.85% cpu) law.Bliss rm /h/cygwin/1G # rsync using SMB/CIFS law.Bliss time rsync 1G /h/cygwin/ 29.18sec 3.52usr 3.08sys (22.65% cpu) You might try reinstalling 3.0.9 and see if that still works -- would help narrow it down to whether or not it is in cygwin or in rsync. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Disable xterm auto-wrap: Mess up vi-like command line
Paul wrote: If I disable auto-wrap, the vi editing at the comand line misbehaves when the line being edited is long, especially when yanking a lot of text and pasting it. I suppose that this might be technically correct behaviour, since an extra long command line needs to wrap in order to see it properly. But I use the vi command line exclusively, and almost always, I don't want autowrap in the results from commands being sent to the screen. Is there a way to get both at the same time, without having to always toggle the xterm autowrap? --- What do you mean by mess up? It shouldn't. I just cut and pasted some text from an xterm into an editor, and the lines weren't split... they got copied as one line. However, if I was to cut from a Windows Console window (cmd.exe for example), it DOES, physically, split long lines. It's a property of the console. The main problem I've seen in bash is when you paste content that has tabs in it. Then bash tries to auto complete in the middle of your typing... often asking a question or pausing -- which means it *swallows* up the tab and 1-2 keys after the tab. It didn't use to do this back in the 3.x series, but was added as a new feature in the 4.x series. I ended up changing my completion character to BACKQUOTE to try to get around this. Maybe tabs are causing your problem? Example. At a prompt, I typed: cat CR completion char (I hit enter after that first quote and went to the next line and hit my completion char (BACKQUOTE `), Then I got: cat Display all 186 possibilities? (y or n) --- At this point, whatever character is next in my paste buffer will be swallowed up (in addition to the completion character). --- Since the long line cut/paste worked for me in 'xterm', that's why I thought maybe you were hitting bash'es input mangling-feature!... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Disable xterm auto-wrap: Mess up vi-like command line
Paul wrote: If I disable auto-wrap, the vi editing at the comand line misbehaves when the line being edited is long, especially when yanking a lot of text and pasting it. I suppose that this might be technically correct behaviour, since an extra long command line needs to wrap in order to see it properly. But I use the vi command line exclusively, and almost always, I don't want autowrap in the results from commands being sent to the screen. Is there a way to get both at the same time, without having to always toggle the xterm autowrap? --- What do you mean by mess up? It shouldn't. I just cut and pasted some text from an xterm into an editor, and the lines weren't split... they got copied as one line. However, if I was to cut from a Windows Console window (cmd.exe for example), it DOES, physically, split long lines. It's a property of the console. The main problem I've seen in bash is when you paste content that has tabs in it. Then bash tries to auto complete in the middle of your typing... often asking a question or pausing -- which means it *swallows* up the tab and 1-2 keys after the tab. It didn't use to do this back in the 3.x series, but was added as a new feature in the 4.x series. I ended up changing my completion character to BACKQUOTE to try to get around this. Maybe tabs are causing your problem? Example. At a prompt, I typed: cat CR completion char (I hit enter after that first quote and went to the next line and hit my completion char (BACKQUOTE `), Then I got: cat Display all 186 possibilities? (y or n) --- At this point, whatever character is next in my paste buffer will be swallowed up (in addition to the completion character). --- Since the long line cut/paste worked for me in 'xterm', that's why I thought maybe you were hitting bash'es input mangling-feature!... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Problem interaction betweenWindows 8.1, Microsoft Account mintty.exe
Stephen Brown wrote: When I then go to compile a program, it fails because of the space in the pathname. Did I miss something? Um... I think so: What was the failure message?? What command did you type in, and what was the output? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rsync still broken
Frank Fesevur wrote: And yesterday I saw that my backup *completely* failed because of these errors: @ERROR: setgid failed rsync error: error starting client-server protocol (code 5) at main.c(1653) [Receiver=3.1.0] ERROR: /usr/bin/rsync returned 5 while processing rsync://192.168.200.208/backup-d/DataShares/ @ERROR: setgid failed rsync error: error starting client-server protocol (code 5) at main.c(1653) [Receiver=3.1.0] ERROR: /usr/bin/rsync returned 5 while processing rsync://192.168.200.208/backup-d/DataGit/ @ERROR: setgid failed It sounds like the group you are in on cygwin doesn't exist or you are not in it on your target machine. what group are you in on the windows machine? if you type 'id', the 2nd number should be your primary gid. uid=1234(Bliss\law) gid=123(lawgroup) groups=123(lawgroup)... Then the question is, does your groupname exist on the server you are transferring it to? (or if you are using '--numeric-ids, is your group# (gid) the same on the server you are transferring files to? If not, are you using the --usermap and/or --groupmap options to map your Windows ID's to your server's ID's? Maybe you have already verified this, but usually when I get errors in a transfer, it's because the UID's or user/groupnames on my windows machine don't always match what is on my server -- they mostly do, but I do see errors occasionally in it trying to set things. You can also try the --fake-super option -- that might fake the id's enough for it to work... Good luck! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bug? attempt to suspend = kill process?
Thomas Wolff wrote: Could signal transfer possibly use Windows in a way that does not have this effect? (Windows experts...) -- --- Utils like 'processhacker' (on source forge), have a suspend funtion that allows you to suspend and continue both processes and threads, I noticed a 2nd copy of bash that gets created between the original shell and the win process (to handle stdio pipes, perhaps?), so should be possible...but the exact mechanism... Didn't know it was common knowledge for all win-progs to behave that way (at one point control-c usually didn't work either), but I thought it might have something to do with the added tty-emulation abilities that allow multiple tty's and such... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug? attempt to suspend = kill process?
I usually run the the windows version of 'Gvim' as it will run even when there is no 'X' running... Usually, to get it to go into the background like it does on linux, it runs an alias in bash: alias gvim='setsid gvim' So it background's appropriately. I had to try something out with a gvim-function and needed to run gvim 'raw'...(w/o the setsid)... It ran, but then I needed to check something in the shell, but gvim had not backgrounded, so I tried pressing ^z, as I would on linux (actually ^y in my usage). In the console window, I got a message that it had stopped like I would in linux: gvim Stopped but actually what happened was that it was killed. ... so.. why no suspend?... it seems like it was trying? FWIW, tty settings: stty -a speed 38400 baud; rows 32; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^X; eof = ^D; eol = undef; eol2 = undef; swtch = ^Z; start = ^Q; stop = ^S; susp = ^Y; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo -echoe -echok -echonl -noflsh -tostop -echoctl -echoke -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
unclear wording on getfacl manpage (--all != ALL)
on the CYGWIN getfacl manpage, it has -a, --all display the filename, the owner, the group, and the ACL of the file -- But in the linux version it says: -a, --access Display the file access control list. -- The --all in the cygwin cygwin version sounds like it should display all ACL-related entries, but it really only displays the inode-specific acl on directories. To display all ACL-related entries, one uses no parameter. The usage of --all to indicate the option limits output to only the inode-specific part is confusing and unclear. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Failure in merging win-env vars into post-'login'...
BTW, FWIW, when I 'remotely login', now, and try to use win-env vars: /Users/law.Bliss/bin/dumphive: line 11: USERPROFILE: unbound variable more than one of my scripts and other programs fail due to USERPROFILE being null. Is it possible to preserve that? maybe a file in /etc/ could specify which variables to preserve (or set) on login. I often launch windows programs from my bash shell -- especially things like explorer, or windows gvim... (generally I use 'bash' as my win-shell. Last I tried, it worked in comspec as well, but I decided to keep that pointing at cmd since if bash is broken, I might have problems launching a shell to fix it. Tnx! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Failure in merging win-env vars into post-'login'...
BTW -- the problem is (you probably already knew this) in 'cygwin.dll', since to restore password-less login, I just copied in the cygwin.dll from the previous version (i.e. just that file), restarted inetd, and it worked. BTW -- don't forget the .rhosts in your home dir. Just experimented with my .rhosts This is a oddity ... The entry that works is the entry without the domainname before my username! either short or long name, upper or lower case, but the entries with the domain name in front of them don't work so... these work: athenae law athenae.hs.tlinx.org law Athenae law Athenae.hs.tlinx.org law These do not: athenae Bliss\law athenae.hs.tlinx.org Bliss\law Athenae Bliss\law Athenae.hs.tlinx.org Bliss\law But it does log me in as the domain user. Note my passwd file has both: Bliss\law (domain account) and law (local account with different home directory) -- the Bliss has my PDC's domain (machine id). the local has whatever window's created when I first setup the computer... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Failure in merging win-env vars into post-'login'...
Corinna Vinschen wrote: - Can you please start inetd under strace, once under 1.7.33, once under the 1.7.34 test DLL and then log in as you usally do? This requires some patience because under strace the whole process of logging in will become almost unbearably slow. ~20 seconds? With the test DLL, you can stop immediately after the password prompt shows up. --- I trimmed both of the traces in gvim to the point when they both first call -bash. I *was* able to login *with* my password under the test release. It placed me in the same home directory -- so I ran getent there as well: Bliss\law:unused:5013:201:L A Walsh, Trust Technologies, tlinx.org,U-Bliss\law,S-1-5-21-3-7-3-5013:/Users/law.Bliss:/bin/bash I think that is the same output as before. I take it you're starting inetd from the command line of a local session, right? Usually from WIN-R (run) since I don't have a local window open yet until I run inetd -- but that's still a local session, so should be the same, just not the same as a startup from bash or a command line. The setup is dead simple then: $ strace -o inetd-1.7.33.trace inetd [your inetd options] $ strace -o inetd-1.7.34.trace inetd [your inetd options] --- No options are passed in. The only file I think I needed to change was '/etc/inetd.conf' (also attached). Other than that the binaries need to be installed (doy!)... Both traces are attached in xz format. Then send the traces, please, compressed and attached. -- done - Can you give me a short, concise description how you set up inetd/rlogin so I can try to reproduce this locally? --- Just the /etc/inetd.conf.. my 'terminal client' then uses the rlogin protocol and feeds it my systemname (localhost didn't work, but the shortname 'athenae' does) and my Userid 'Bliss\law'. If you want to try the same terminal client, you can download it for a 30-day trial from http://www.vandyke.com/products/securecrt/index.html I am not running under the latest release as my 'free updates' expired (I'm running 7.1.1 x64 version, current is 7.3). Note: when you purchase, you get free updates for some period after that, but the client itself doesn't expire...so it's been a pretty good value (you can set it for normal scrolling or jump scrolling.. among many other configurables). Hope this was everything ... ? Thanks, Corinna inet733.trc.xz Description: Binary data inet-1.7.34.trc.xz Description: Binary data # See man 8 inetd for more information. # # If you make changes to this file, either reboot your machine or restart # inetd, so that it will re-read this file. # net stop inetd / cygrunsrv -E inetd / telinit 1 # net start inetd / cygrunsrv -S inetd / telinit 3 # (depending on how the inetd service is installed on your machine. See # /usr/share/doc/Cygwin/inetutils.README for more information) # # service_name sock_type proto flags user server_path args # #echostream tcp nowait rootinternal #echodgram udp waitrootinternal #discard stream tcp nowait rootinternal #discard dgram udp waitrootinternal #daytime stream tcp nowait rootinternal #daytime dgram udp waitrootinternal #chargen stream tcp nowait rootinternal #chargen dgram udp waitrootinternal #timestream tcp nowait rootinternal #timedgram udp waitrootinternal # # The canonical method of calling external services is # to specify them directly: # ftp stream tcp nowait root/usr/sbin/ftpd ftpd # However, by default on cygwin we call them instead via # the 'tcpd' access-control wrapper for security reasons. # tcpd is not part of the inetutils proper, but is provide # by the tcp_wrappers package. If you enable (uncomment) any # of the services below, you need to also configure your # windows firewall AND /etc/hosts.allow to enable the affected # ports. See /usr/share/doc/Cygwin/inetutils.README and # 'man hosts_access' for more information. # # These are standard services. # #ftp stream tcp nowait root/usr/sbin/tcpd ftpd telnet stream tcp nowait root/usr/sbin/telnetd telnetd # # Shell, login, exec and talk are BSD protocols. # shell stream tcp nowait root /sbin/rshd -h login stream tcp nowait root /sbin/rlogind -h execstream tcp nowait root /sbin/rexecd -h #shell stream tcp nowait root/usr/sbin/tcpd rshd -L #login stream tcp nowait root/usr/sbin/tcpd rlogind #execstream tcp nowait root/usr/sbin/tcpd rexecd #talkdgram udp waitroot/usr/sbin/tcpd talkd #ntalk dgram udp waitroot/usr/sbin/tcpd talkd # # The Internet UUCP service. # # uucpstream tcp nowait uucp/usr/sbin/tcpd uucpd -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/
Re: Failure in merging win-env vars into post-'login'...
Corinna Vinschen wrote: It seems your home dir is different for some reason. What does your /etc/nsswitch.conf look like (if you have one)? What does getent passwd your username Same as it ever was... law.Bliss getent passwd Bliss\\law Bliss\law:unused:5013:201:L A Walsh, Trust Technologies, tlinx.org,U-Bliss\law,S-1-5-21-3-7-3-5013:/Users/law.Bliss:/bin/bash print in a local mintty session, and what does it print in a remote session via rlogin? Why on earth are you still using rlogin anyway instead of ssh? They print the same thing. mintty doesn't have a smooth scroll option -- only jump scroll, so I can't see anything that scrolls. It seems like if I cat 20 pages of text, mintty show me the last page, but I don't see an option to turn off jump scrolling. I'm not still using rlogin - I just switched to it recently for being able to open a local console/shell window using a terminal It's about 3-5 times faster than ssh. For added security (besides the fact that my login isn't going out on the network for a local console, my windows machine isn't directly connected to the internet (behind a proxy) so it makes more sense to not use encryption. It also allows me to use SecureCRT (a remote terminal emulator) that I use to log into my server (even though I have a dedicated connection to the server). It *looks*, at this point that my userid isn't being passed from inetd to rlogind so it can read the .rhosts file in my WIN-HOME (USERPROFILE or HOMEDRIVE:\HOMEPATH). Your userid is bound to you token's SID. For accessing .rhosts the home dir in your passwd entry must match. --- Well, it DOES with the old code... with the test code I don't know. I DO have a local passwd file and my user entry is the same as the above. My nsswitch.conf is the default (all commented out). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] -- merging win-env vars into post-'login'-wiped-ENV
Corinna Vinschen wrote: On Jan 14 19:39, Linda Walsh wrote: Corinna Vinschen wrote: - When spawning a process under another user account, merge the user's default Windows environment into the new process' environment. Will this affect using inetd to spawn rlogind = login. https://cygwin.com/ml/cygwin/2014-12/msg00013.html https://cygwin.com/ml/cygwin/2014-12/msg00102.html Corinna -- Don't know why yet, but it does not work very well. 1) Instead of just logging me in, it now asks for my password. 2) When I typed the passwd it hung... 2a) could have happened because the X11 server wouldn't start/died on startup. It's log showed: XWin.0.log (press RETURN)Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.16.3.0 OS: CYGWIN_NT-6.1 Athenae 1.7.34(0.283/5/3) 2015-01-14 12:28 x86_64 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (Win64) Package: version 1.16.3-1 built 2014-12-30 XWin was started with the following command line: /usr/bin/XWin -dpi 120 -nomultimonitors -clipboard -ac -unixkill -nowinkill -wgl -bs -fp /usr/share/fonts/TTF,built-ins,/usr/share/fonts/Type1,/usr/share/fonts/misc,/us r/share/fonts/100dpi -multiwindow ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 2560 h 1600 winInitializeScreenDefaults - native DPI x 128 y 128 [446019.915] (II) xorg.conf is not supported [446019.915] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more in formation [446019.915] (++) FontPath set to /usr/share/fonts/TTF,built-ins,/usr/share/fon ts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi [446019.915] LoadPreferences: Loading /Users/law.Bliss/.XWinrc [446019.915] LoadPreferences: Done parsing the configuration file... [446019.978] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowD DNL [446019.978] winDetectSupportedEngines - Returning, supported engines 0015 [446019.978] winSetEngine - Multi Window or Rootless = ShadowGDI [446019.978] winScreenInit - Using Windows display depth of 32 bits per pixel [446019.993] winAllocateFBShadowGDI - Creating DIB with width: 2560 height: 1600 depth: 32 [446019.993] winFinishScreenInitFB - Masks: 00ff ff00 00ff [446019.993] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [446019.993] Warning: Locale not supported by X, falling back to 'C' locale. [446020.024] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll' [446020.165] (II) AIGLX: Testing pixelFormatIndex 5 [446020.196] GL_VERSION: 4.4.0 XWin.0.log lines 1-33/53 58%[446020.196] GL_VENDOR: NVIDIA Corporation [446020.196] GL_RENDERER:GeForce GTX 590/PCIe/SSE2 [446020.196] (II) AIGLX: enabled GLX_SGI_make_current_read [446020.196] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [446020.196] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [446020.196] (II) AIGLX: enabled GLX_SGIX_pbuffer [446020.196] (II) AIGLX: enabled GLX_ARB_multisample and GLX_SGIS_multisample [446020.196] (II) 482 pixel formats reported by wglGetPixelFormatAttribivARB [446020.196] (II) AIGLX: Set GLX version to 1.4 [446020.212] (II) 323 fbConfigs [446020.212] (II) ignored pixel formats: 0 not OpenGL, 54 RBGA float, 69 RGBA un signed float, 0 unknown pixel type, 36 unaccelerated [446020.212] (II) GLX: Initialized Win32 native WGL GL provider for screen 0 [446020.212] (EE) XKB: Couldn't open rules file /usr/share/X11/xkb/rules/base [446020.212] (EE) XKB: Failed to load keymap. Loading default keymap instead. [446020.212] (EE) XKB: Couldn't open rules file /usr/share/X11/xkb/rules/base [446020.212] XKB: Failed to compile keymap [446020.212] Keyboard initialization failed. This could be a missing or incorrec t setup of xkeyboard-config. [446020.212] (EE) Fatal server error: [446020.212] (EE) Failed to activate core devices.(EE) [446020.212] (EE) Server terminated with error (1). Closing log file. XWin.0.log lines 20-53/53 (END) - When I tried logging in as root instead of as me, the console window immediately disappeared (have seen that before when I was trying to get rlogin to work in the first place, so likely unrelated. However, it is ignoring my ~/.rhosts file (into which I put nearly every combination I could think of to get this to work... athenae Bliss/law athenae.hs.tlinx.org Bliss/law Athenae Bliss/law Athenae.hs.tlinx.org Bliss/law localhost Bliss\law athenae Bliss\law athenae.hs.tlinx.org Bliss\law Athenae Bliss\law Athenae.hs.tlinx.org Bliss\law localhost law athenae law athenae.hs.tlinx.org law Athenae law Athenae.hs.tlinx.org law id put out 'mostly correct stuff'... Since my id's have the domain before the ID: uid=5013(Bliss\law) gid=201(Bliss\lawgroup) groups=201(Bliss\lawgroup),197626(Athenae+Netmon Users),197625(Athenae+pulse-access),197624(Athenae+pulse-rt),544(Administrators),555(Remote Desktop Users),545(Users),4(INTERACTIVE),66049
Re: Failure in merging win-env vars into post-'login'...
Corinna Vinschen wrote: On Jan 16 01:43, Linda Walsh wrote: Prior to this, when I logged on using local credentials, I would have a blank hostname. I.e. -- using 'X11' as an example, when I log in locally, I see no hostname in my shell-prompt. But when I log in to another system, then my path is prefixed with the hostname. So... why did I need the local hostname with a +?? Does https://cygwin.com/preliminary-ntsec.html answer that question? --- Not entirely. But don't know that it is related to the problem I'm seeing. As it is only being applied to locally created groups, I'm not going to worry about it too much (i.e. it doesn't interfere with my samba-3.6.28-winbind credentials, and more interested in why it didn't look at /.rhosts in my home directory.). I have a feeling the X-server died because installing the test cygwin wiped out my share partition (on a local mount, but one that cygwin turns into a symlink and overwrites)... A Cygwin install never wipes out /usr/share, except for files going to be replaced. Also, /usr/share is NOT created as symlink, but as directory. SIDEISSUE: --- If it already exists (as a Windows junction), it is treated as a symlink and not a file-system mount (as MS terminology describes it, as it is not the same as a 'symlink' on windows but is more like a mount-point on linux -- as we have previously discussed... ;-/. As such, even though nothing was installed at /usr/share, I did have many docs and manpages installed in /usr/share/doc and /usr/share/man, but -- WHY must the install procedure delete perfectly good path components if it is not *installing them*, (but installing files *under them*). ^^^SIDE ISSUE^^^ Nevertheless, in tracing (w/process monitor) through an attempted login with the test-DLL, at no time did anything access my home directory (i.e. nothing read .rhosts in home). Before this change that file was read and allowed me to login w/o a password, WITH the network credentials of whoever started 'inetd' (i.e. if it was started automatically by as a service, I won't see my mounts, but it if was started by me, from my current login-session, I see the same mounts as in my normal login session). I.e. it was a way of opening a local command-line window using a 3rd party (SecureCRT) TTY tool that supports rlogin/rsh in addition to ssh and a few others). It *looks*, at this point that my userid isn't being passed from inetd to rlogind so it can read the .rhosts file in my WIN-HOME (USERPROFILE or HOMEDRIVE:\HOMEPATH). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Failure in merging win-env vars into post-'login'...
Linda Walsh wrote: It *looks*, at this point that my userid isn't being passed from inetd to rlogind so it can read the .rhosts file in my WIN-HOME (USERPROFILE or HOMEDRIVE:\HOMEPATH). Not quite sure how 'rlogin.exe' as spawned by inetd.exe gets my UID as it's env already seems clear (Has PATH(long), SYSTEMDRIVE SYSTEMROOT and WINDIR)... but nothing identifying my home dir, except the 'token' as passed from 'inetd.exe' which I re-started manually, interactively, after re-installing the earlier version of cygwin and cycling all the cygwin processes. However 'rlogin' DOES read C:\Users\law.Bliss\.rhosts in the previous cygwin version (1.7.33-1) and is able to launch 'login' which launches 'bash' as a login shell w/no PW. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] -- merging win-env vars into post-'login'-wiped-ENV
Corinna Vinschen wrote: On Jan 14 19:39, Linda Walsh wrote: Corinna Vinschen wrote: - When spawning a process under another user account, merge the user's default Windows environment into the new process' environment. Will this affect using inetd to spawn rlogind = login. https://cygwin.com/ml/cygwin/2014-12/msg00013.html https://cygwin.com/ml/cygwin/2014-12/msg00102.html --- *pong* sorry, missed that message (it wasn't in my spam folder, it was in my cygwin folder...which claims it has over 1000 new messages (out of 2184)sometime I don't read them all? Note -- this is more likely to happen if I'm not one of the recipients (on 'To', or 'Cc' line). Mail directed to me ends up in a much, lower-volume 'inbox' (one where the person actually responded to me).Vs. message only sent to the list I somtimes miss unless I remember to look for it. will try to install the new one and see if it still happens... Thanks! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [Mingw-w64-public] How to recognize symlinks in WIN32?
David Macek wrote: I assume you could detect them using cygwin *stat calls. Maybe by compiling against cygwin headers and cygwin1.dll, or maybe by extracting the relevant code from cygwin sources (you'd have to check the relevant licenses). Are you looking for https://cygwin.com/cygwin-ug-net/using-cygwinenv.html down under 'winsymlinks'? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] -- merging win-env vars into post-'login'-wiped-ENV
Corinna Vinschen wrote: - When spawning a process under another user account, merge the user's default Windows environment into the new process' environment. Will this affect using inetd to spawn rlogind = login. Right now all ENV vars are cleared by login -- which means the user can't find their home directory (or their windows HOME DIR -- aka USERPROFILE, HOME, HOMEDRIVE, HOMEPATH, PATHHOME among others. It's impossible for a wiped ENV process to pick up where it should be -- initialize itself, etc. Right now, I'm using a horrible hack of reading in a valid copy of my ENV from a a earlier save in a valid session. Is there any less horrible hack to get around this? BTW -- am not getting the warning about DOS paths when BASH looks for my MAILBOX anymore! Thanks! Note: I am trying to login as the *same* user (not a different user). So far, I have had to start inetd manually after login to have it be in the same 'session', else it starts a new session with no drives mounted. FWIW, I've found using rlogin allows me to use my own terminal emulator that, unlike cmd.exe, actually supports UTF-8, and it scrolls (not jump scroll), WAY fast... easily 2-3x using a windows-type console (as in 'Console2). Thanks! -linda -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
solution for package startup scripts changing: do your own (was Re: run.exe will not work with upgrade from 1.14.4 to 1.16.3)
Laurens Blankers wrote:
On 2-1-2015 21:10, schilpfamily wrote:
this has worked for years, now when i run this command, a window very
briefly blinks into existence but then goes away. any idea why this
would stop working now?
Because the default options in the distribution provided
startup script changed to a more secure setting, consistent with
upstream changes and the general atmosphere of security paranoia that
is gradually eroding usability (as security issues get alot more
attention than usability -- so much so, that while a benefit of computers
was that they could adapt to the user for a friendly user experience,
the opposite is becoming the standard. I.e. users are expected to
adapt themselves to the changing machine programs.
I start my X server on login -- which means it has to work
when called at login -- and I wanted to make sure I could pass
custom arguments for the font path (among other things). As
a result I simply wrote my own startup script that has it's
own defaults. I expect it to work until some argument I expect
to be there is deleted.
I don't instantly get new features and benefits that might
be invoked from the distribution script, but usually it starts, and
every once in a while I review it and the cygwin start scripts to see
if there is something I should change. But at least I don't get
caught by this particular problem.
I *do* still get caught by the installer overwriting
Windows mount points with physical directories which causes
various programs to stop functioning until I move the updated
files to the 'mount-point' and change the physdir back to
a mount point.
Anyway, ---
The script is started by a shortcut in:
C:\Users\YOURUSERID\AppData\Roaming\Microsoft\Windows\Start
Menu\Programs\Startup
That has a shortcut to 'bash' with arguments:
(Target:) C:\bin\bash.exe -c '/bin/setsid %USERPROFILE%/bin/startxwin.sh'
(Start in:) %HOMEDRIVE%%HOMEPATH%
(Run:) Minimized
It is also an icon on my 'Quick Launch' bar (i.e. in directory):
C:\Users\YOURUSERID\AppData\Roaming\Microsoft\Internet Explorer\Quick
Launch
---startxwin.sh---
#!/bin/bash
# (c) LA Walsh 2004-2014, licenced under GPLv2
#export DISPLAY=:0
#export XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
#export XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
#export XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
#export XNLSPATH=/usr/X11R6/lib/X11/locale
#unexport XAPPLRESDIR XCMSDB XKEYSYMDB XNLSPATH
# see cygwin Xwin for more option examples
# relevant ops:
# -multiwindow = use windows manage; not w/(-rootless|-fullscreen)
# -clipboard = use built-in version (integrated w/windows)
# -unixkill = Enable Ctrl-Alt-BS as X-server shutdown cmnd
# -nowinkill = Disable Alt+F4 as a server shutdown key combination.
# -trayicon = (default) windows tray icon enabled
mount -c /
export PATH=/bin:$(/bin/cygpath $USERPROFILE)/bin:$PATH #ensure our
bin is 1st
shopt -s expand_aliases extglob
alias notify=$(type -P notifu)
alias int=declare\ -i
alias sub=function
alias xset=$(type -P xset);
alias array=declare\ -a
alias my=declare
export DISPLAY=${DISPLAY:-:0}
sub xup {
local stat
read -t .1 stat $(xset q /dev/null; echo $?)
return $stat
((-1))
}
sub Xwin_pids {
( cd /proc
for p in +([0-9])/ ;do
p2=${p%/}
prg=$(${p2}/exename)
if [[ $prg =~ .*XWin ]]; then
printf %d:%s\n $p2 $prg
fi
done
)
}
sub Xwin_pid {
array Xprgs
readarray Xprgs (Xwin_pids)
if ((!${#Xprgs[@]}));then
echo 0
return 1
fi
my x=${Xprgs[0]}
my pid=${x%%:**} prg=${x##*:}
array out=( $pid $prg)
printf %s ${out[@]}
printf \n
return 0
}
sub Xwin_running {
int pd; my pg
read pd pg (Xwin_pid)
return $(((!pd)))
}
export -f Xwin_pids Xwin_pid
sub tidy_old_Xwin {
local -a sigs=(TERM TERM KILL) # try 2 TERMs then KILL upto maxsigs
int pd; my pg
int maxsigs=3 lastsig=${#sigs[*]}
while ((1)); do
read pd pg (Xwin_pid)
((pd)) || break
#int i=--maxsigslastsig ? lastsig:maxsigs
kill -${sigs[--maxsigslastsig ? lastsig:maxsigs]} $pd
((maxsigs)) || break
sleep 1
done
rm -fr /tmp/.X11-unix
}
sub get_dpi {
dpi=$(regtool -d get '/HKLM/Software/Microsoft/Windows
NT/CurrentVersion/FontDPI/LogPixels')
# check for insane values
((dpi50||dpi400)) dpi=96
echo $dpi
}
sub get_fontpath {
local
fontpath=/usr/share/TTF:tcp/ishtar:7100,built-ins,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi
echo -n $fontpath
}
sub start_XWin {
local
fontpath=/usr/share/fonts/TTF,built-ins,/usr/share/fonts/Type1,/usr/share/fonts/misc,/usr/share/fonts/100dpi
int dpi=$(get_dpi)
cmd=/bin/run /bin/XWin ${dpi:+-dpi $dpi}
-nomultimonitors -clipboard -ac -unixkill -nowinkill -wgl
-bs -fp $fontpath -multiwindow
echo cmd=$cmd
$cmd
}
declare -a default_switches=(-dpi -clipboard -unixkill -nowinkill -bs
-ac -fp -multiwindow -wgl)
readarray -t args (
a=$default_switches[@];
Re: RFD: cygwin ACLs: NFS or POSIX model: ease in adapting to CIFS ACLs?
Larry Hall (Cygwin) wrote: On 12/21/2014 06:25 PM, Linda Walsh wrote: I seem to remember that the cygwin ACL's were based on NFS acls not the POSIX ACL's. I can't speak to the specific issues you're raising or shed any light on whether they are actually issues with Cygwin. As far as the Cygwin implementation is concerned, I believe the links below shed some light on the original implementation and the direction things are heading. At this time, the first link still refers to a test version of the Cygwin package, though the version number is different. https://www.marshut.net/kqrriw/test-release-cygwin-1-7-33-1.html https://cygwin.com/preliminary-ug/ntsec.html Hope this helps. --- Indeed, though not in the details, but that may not be necessary depending on what this means: - Revamp Solaris ACL implementation to more closely work like POSIX ACLs are supposed to work. Finally implement a CLASS_OBJ emulation. Update getfacl(1)/setfacl(1) accordingly. --- Not very specific, but may have addressed any issues in that area. The part that looks a bit more hairy are the auto-RID-UID mappings and how those will work with existing UID/RID mappings coming from a samba server... Specifically, will cygwin support UID's 32 bit? I found to cleanly separate various login service types into contiguous blocks was good to multiply by large numbers. I'm thinking cygwin already supports the longer numbers or things like 'TRUSTED INSTALLER' wouldn't show with the right owner or be changeable in cygwin... Thanks for the reply... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RFD: cygwin ACLs: NFS or POSIX model: ease in adapting to CIFS ACLs?
I seem to remember that the cygwin ACL's were based on NFS acls not the POSIX ACL's. From this snippet I read on the Samba list, it seems there are some very difficult [nightmarish] cases where NFS causes CIFS compatibility problems. Is this only NFSv4 (does cygwin model v4 or v3?) that had these problems? Would it simplify anything for cygwin to be using POSIX acl's -- in so much that those seem to be more str8forward in functionality mapping? I know nothing about NFS ACL's or how they are different from POSIX ACL's, but wondered also if code in the linux kernel or samba projects might have any useful bits to use in cygwin only from the basis of what this person states about their compatibility? It may also be this is a dead issue without someone to do the work, but am just wondering if it is, in any fixes or enhancements to the Cygwin ACL work something that might be good to consider as a direction for either, new or maintenance (or both) work? Just seems like code in samba that presents a CIFS UI/API to the 'user' from a POSIX ACL UI/API backend, might have some similarities between cygwin code using CIFS to talk to the OS and presenting a POSIX ACL UI/API to the 'user'? Original Message Subject:Does Samba 4 actually respect Unix file acls? Date: Sat, 20 Dec 2014 20:42:11 -0500 From: Nico Kadel-Garcia nka...@gmail.com To: Rufe Glick rufe.gl...@gmail.com CC: sa...@lists.samba.org sa...@lists.samba.org References: 931136554.20141219124...@gmail.com On Fri, Dec 19, 2014 at 12:47 PM, Rufe Glick rufe.gl...@gmail.com wrote: Hello, After researching the subject on the internet I concluded that Samba should take into account Unix file acls. During my tests I found the opposite. I'm sorry, but exactly which set of file acl's are you referring to? NFS v4, prehaps or Linux availaility? CIFS ACL's? Because I've got to warn you, I pursued getting NFS, and CIFS clients to work well with Samba and Netapps, with Linux and Windows clients, and it was a clusterfutz to manage. RHEL didn't include decent GUI's to manage NFSv4 ACL's, the are profound hierarchy differences between CIFS and NFSv4, and the edge cases were nightmarish. Frankly, for most environments, the POSIX permissions are not only vastly simpler, but the software compatibly is so much simpler as to help make the code more stable and thus safer. I remember even Jeremy Allison referring to the NFSv4 code in Samba as spaghetti code. --- -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: remote xterm's can't open display after upgrade
JimE wrote:
Hi Don,
I'm in the same boat. I just upgraded cygwin and now I can't get remote xterms to
display on the local machine.
Question -- Is your local machine on a closed net?
I.e. My windows machine is on a local subnet (example: 192.168.x.y)
that isn't
(usually) exposed to the internet.
1st thing to note, is that my win X server starts automatically
when I log into windows (well it usually does unless some upgrade[sic]
makes something incompat), BUT, less likely to have problems, as
I start the X-server via my *own* script in my homedir's bin dir.
I.e. the shortcut on my QuickLaunch Bar (yeah, running W7 and still
using that...)... has
Target: C:\bin\bash.exe -c '%USERPROFILE%/bin/startxwin.sh'
Startin: %HOMEDRIVE%%HOMEPATH%
---
my startxwin.sh is mostly free of non-cygwin deps, except
for a tray-message util, notify which lets me put up messages
if the server is already running and such.
I'll leave in the comments (mostly NOTES to self or
OLD code...)... but if you know shell script, shouldn't be
hard to modify to your use case.
Some things (like a mount -c /) at the beginning
of the script have been added over the years to
increase robustness.
This script hasn't been cleaned for looking good
or best coding style, but given how often I need to
maintain or change it, I haven't been motivated.
It has disabled code that tried to start dbus, but
it didn't work reliably, so it's commented out.
Parts were rewritten to try to minimize use of non-shell,
external commands (minimize deps, efficiency).
Note 1: If you want to use this in an unsecure network,
then you need to start this through an ssh command to
the remote machine and not reset the DISPLAY...
Note 2: one thing this script does that the cygwin
script does not do -- it tries to read your display's
DPI and set the corresponding option in the X-display.
-extra config file: (optional)
~/.mind/Xserver-dflt-overrrides
+ac
-bash script: startxwin.sh
#!/bin/bash
# (c) LA Walsh 2004-2014, licenced under GPLv2 and/or to nice people
#export DISPLAY=:0
#export XAPPLRESDIR=/usr/X11R6/lib/X11/app-defaults
#export XCMSDB=/usr/X11R6/lib/X11/Xcms.txt
#export XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
#export XNLSPATH=/usr/X11R6/lib/X11/locale
#unexport XAPPLRESDIR XCMSDB XKEYSYMDB XNLSPATH
# see cygwin Xwin for more option examples
# relevant ops:
# -multiwindow = use windows manage; not w/(-rootless|-fullscreen)
# -clipboard = use built-in version (integrated w/windows)
# -unixkill = Enable Ctrl-Alt-BS as X-server shutdown cmnd
# -nowinkill = Disable Alt+F4 as a server shutdown key combination.
# -trayicon = (default) windows tray icon enabled
mount -c /
export PATH=/bin:$(/bin/cygpath $USERPROFILE)/bin:$PATH #ensure our
bin is 1st
shopt -s expand_aliases extglob
alias notify=$(type -P notifu)
alias int=declare\ -i
alias sub=function
alias xset=$(type -P xset);
alias array=declare\ -a
alias my=declare
export DISPLAY=${DISPLAY:-:0}
sub xup {
local stat
read -t .1 stat $(xset q /dev/null; echo $?)
return $stat
((-1))
}
sub Xwin_pids {
( cd /proc
for p in +([0-9])/ ;do
p2=${p%/}
prg=$(${p2}/exename)
if [[ $prg =~ .*XWin ]]; then
printf %d:%s\n $p2 $prg
fi
done
)
}
#sub Xwin_pid { echo $(/bin/ps -s|/bin/awk -- '/\?.*XWin/{print $1}') ; }
sub Xwin_pid {
array Xprgs
readarray Xprgs (Xwin_pids)
if ((!${#Xprgs[@]}));then
echo 0
return 1
fi
my x=${Xprgs[0]}
my pid=${x%%:**} prg=${x##*:}
array out=( $pid $prg)
printf %s ${out[@]}
printf \n
return 0
}
sub Xwin_running {
int pd; my pg
read pd pg (Xwin_pid)
return $(((!pd)))
}
export -f Xwin_pids Xwin_pid
#sub Xwin_pid { echo $(/bin/ps -s|/bin/awk -- '/\?.*XWin/{print $1}') ; }
#export -f Xwin_pid
#sub Xwin_running { [[ $(Xwin_pid) ]] ; }
#export TERM=15 KILL=9
sub tidy_old_Xwin {
local -a sigs=(TERM TERM KILL) # try 2 TERMs then KILL upto maxsigs
int pd; my pg
int maxsigs=3 lastsig=${#sigs[*]}
while ((1)); do
read pd pg (Xwin_pid)
((pd)) || break
#int i=--maxsigslastsig ? lastsig:maxsigs
kill -${sigs[--maxsigslastsig ? lastsig:maxsigs]} $pd
((maxsigs)) || break
sleep 1
done
rm -fr /tmp/.X11-unix
}
sub get_dpi {
dpi=$(regtool -d get '/HKLM/Software/Microsoft/Windows
NT/CurrentVersion/FontDPI/LogPixels')
# check for insane values
((dpi50||dpi400)) dpi=96
echo $dpi
}
sub get_fontpath {
local
fontpath=/usr/share/TTF,built-ins,/usr/share/fonts/misc,/usr/share/fonts/100dpi
echo -n $fontpath
}
sub start_XWin {
local
fontpath=/usr/share/fonts/TTF,built-ins,/usr/share/fonts/misc,/usr/share/fonts/100dpi
int dpi=$(get_dpi)
cmd=/bin/run /bin/XWin ${dpi:+-dpi $dpi}
-nomultimonitors -clipboard -ac -unixkill -nowinkill -wgl
-bs -fp $fontpath -multiwindow
echo cmd=$cmd
$cmd
}
declare -a default_switches=(-dpi -clipboard -unixkill -nowinkill
Re: fdisk -l is mute
Marco Atzeri wrote: contrary to help it requires a disk --- Seems like a regression (bug). The idea behind -l (and no arg) was to show ALL disks. If you specify a disk, you no longer see all displayed. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: a batch that executes a command within cygwin?
Marco Atzeri wrote: On 12/14/2014 1:45 PM, Marilo wrote: I would like to make a batch file that executes a command within cygwin. or tells cygwin to execute some commands when it starts. I know I can do C:\cygwin\binncENTER --- And that works but it doesn't run the nc command. Try (in bash): cd /tmp cat /tmp/runmc 'EOF' #!/bin/bash PATH=/bin:/sbin:/usr/local/bin:$PATH nc EOF chmod +x /tmp/runmc ##in Windows (like cmd.exe, you can run it like:... /tmp cmd Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\tmpC:\bin\bash /tmp/runmc C:\bin\bash /tmp/runmc usage: nc [-46CDdhklnrtUuvz] [-I length] [-i interval] [-O length] [-P proxy_username] [-p source_port] [-s source] [-T ToS] [-V rtable] [-w timeout] [-X proxy_protocol] [-x proxy_address[:port]] [destination] [port] I'm interested in running a command (nc for example) within cygwin. --- Maybe the above will get you started? (you may have to adjust paths .. my cygwin is installed in root (sorta), so I don't need to add cygwin to my dos paths...) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFC: 1.7.33 problem with user's home directory
Andrey Repin wrote: Greetings, cyg Simple! Don't forget that CMD will not create a second connection to a \\host\share if Cygwin already has one open. What do you mean by that? $ cd //somehost/someshare $ cmd /c start cmd cmd will complain about UNC paths and start in %WINDIR% instead. Try it the other way around. You'll get the same result. It has nothing to do with cygwin opening it first. It has to do with cmd not handling a \\network\share style address. MS was too lazy to deal with command.com's 1-CurDir / drive scenario that is embedded in the Win32 interface. If you cd to //host/currentdir, //host isn't a drive letter. So what happens when the user uses an absolute path? /tmp... where is that /tmp? Ends up at the root of each drive, but on a UNC-based-net-connection? Undefined. So cmd.exe can't be used on a UNC-based path, only on DOS compatible (drive letter assummed) based-path. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Prob -- included 'setsid' is clearing terminal
Linda Walsh wrote: Yaakov Selkowitz wrote: util-linux-2.24.2-1 The current version of util-linux is 2.25.1-1. --- --- That fixed it! Thanks much! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin Prob -- included 'setsid' is clearing terminal
The setsid command on cygwin seems to have broken recently: /tmp uname -a;setsid date CYGWIN_NT-6.1 Athenae 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin vs. a linux box: Ishtar:/tmp uname -a ;setsid date Linux Ishtar 3.17.3-Isht-Van #1 SMP PREEMPT Sun Nov 16 15:13:22 PST 2014 x86_64 x86_64 x86_64 GNU/Linux Sat Nov 22 18:10:54 PST 2014 It seems to mess up the current tty value: linux: Ishtar:/tmp tty;setsid tty /tmp/tty.out ; cat /tmp/tty.out /dev/pts/6 /dev/pts/6 cygwin: /tmp tty;setsid tty /tmp/tty.out ; cat /tmp/tty.out /dev/pty0 not a tty not a tty??? :-( /tmp cygcheck -f /bin/setsid util-linux-2.24.2-1 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Prob -- included 'setsid' is clearing terminal
Yaakov Selkowitz wrote: WFM: $ tty;setsid tty /tmp/tty.out ; cat /tmp/tty.out /dev/pty1 /dev/pty1 /tmp cygcheck -f /bin/setsid util-linux-2.24.2-1 The current version of util-linux is 2.25.1-1. --- Will try it soon. tnx. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Perl rename
Steven Penny wrote: I noticed that Debian is using Perl rename $ readlink -f /usr/bin/rename /usr/bin/prename $ dpkg --search bin/prename perl: /usr/bin/prename However, Cygwin Perl does not include this file. $ gzip -cd /etc/setup/perl.lst.gz | grep prename | wc 0 0 0 I understand that the util-linux version has the benefit of not needing Perl, however if a user decides to install the Perl package, shouldnt they benefit from the Perl rename as well? --- What benefits does the perl rename have over the normal util-linux version? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BUG: cygwin warning: barfs on domain-based-mboxes; env corrupted by login(-p disabled)
Andrey Repin wrote: Greetings, Corinna Vinschen! The next Cygwin release will have CYGWIN=dosfilewarning set to OFF by default. If anybody thinks it's really worth to keep this option available and ON by default, please speak up. I don't think it's worth the hassle. What little of the programs that is unable to deal with native paths are printing obvious enough error messages to convince the user that they should change their habits. --- Not that I disagree with Corinna's decision, but Andrey's followup doesn't necessarily apply (nor is it important in my case). Bash is testing for the existence of a user's mbox, in the spool directory -- it prints no error if it is not found -- I don't know that it is important that it should as one can [re]set the system mbox path if they want, in the startup scripts. Just that this mbox check uses some internally compiled name that is checked before any user scripts are run. Still doesn't fix the problem of the ENV being zeroed in 'login' which triggered this problem in the first place. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
BUG: cygwin warning: barfs on domain-based-mboxes; env corrupted by login(-p disabled)
cygwin warning: MS-DOS style path detected: /usr/spool/mail/Bliss/law Preferred POSIX equivalent is: /usr/spool/mail/Bliss/law CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames law.Bliss who Bliss\law pty0 2014-10-27 22:39 (Athenae) law.Bliss id uid=5013(Bliss\law) gid=201(lawgroup) groups=201(lawgroup),544(Administrators),545(Users),\ 512(Bliss\Domain Admins),513(Bliss\Domain Users) Upon starting a new cygwin console session -- the first time after boot, I get the above and I can't shut it off because 'login' clears all of the Windows environment (including USERPROFILE) when I use rlogin to login to my local host). I don't know if rlogin also clears the environment, but login pretty clearly does which causes all sorts problems trying to run many (any?) windows based programs. Note, the above mbox check in (all caps) /USR/SPOOL/MAIL/BLISS\LAW happens long before bash has opened it's first rc file, so nothing in bash can be set to disable this problem before it comes out (does Mbox processing before any rc processing). At the very least, login -p should be fixed to work (whereas now it has been explicitly patch to NOT WORK (man login:...) -p Used by getty(8) to tell login not to destroy the environment. This is disabled in the Cygwin version. Can login have the cygwin specific code that disables -p removed? Is there a reason why it is _needed_ (I know it may cause unpredictable results in a multi-user env -- but that can be documented -- otherwise, there is no reliable single-user workaround for the above (and a few other ENV-wiped-based problems). -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty: WINCH-signal to child
Thomas Wolff wrote: Am 19.10.2014 12:11, schrieb Helmut Karlowski: Am 19.10.2014, 09:48 Uhr, schrieb Duncan Roe: bash at least has shopt -s checkwinsize to achieve what you want, That would be a workaround for bash. Ideally every process should forward the WINCH-signal to its parent, or the terminal should walk through the call-tree. Both not very likely to happen. xterm does the same as mintty BTW. There must be something more about it: Mined does resend a received SIGWINCH to its parent (as an application should indeed) and it's actually received by bash as can be confirmed with 'trap echo WINCH SIGWINCH'. Despite of the received signal bash does not adapt its command line width assumption (as can be checked by typing a long line and seeing where it wraps) (unless that option is enabled). Probably a bash bug. Same in mintty as in xterm in all cases. Same on Linux (bash 3.2.39 on Debian on PowerPC), so not cygwin-specific. Do you guys also know there was a change between 4.2 and 4.3 in bash's signal handling? In 4.2, bash used to do child processing inside the parent interrupt which caused problems. In 4.3, bash waits until a key is pressed before propagating any signals. This may be unrelated to whatever problem you are experiencing, but I thought I'd mention you might goog the bash archives on sigwinch and/or winch... (not sure what would be the exact right invocation, but it may not be related to what you are experiencing anyway... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: what path to use that is not DOS??
Eric Blake wrote: On 10/08/2014 01:55 PM, Linda Walsh wrote: I get this message the 1st time logging in via 'rlogin': MS-DOS style path detected: /Windows/System32/cygwin/usr/spool/mail/Bliss/law Preferred POSIX equivalent is: /Windows/System32/cygwin/usr/spool/mail/Bliss/law Could any prefix of that path be a symlink with questionable contents? Cygwin can't use any of the normal methods to find my home and because USERNAME isn't set it tries 'USER'. So for a mail-spool dir it looks for /usr/spool/mail/USER=Bliss\law The backslash is in the USER var. I would say this is a result of logind corrupting the environment and losing all of windows's expected environment. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Running 4096 parallel cat processes on remote share results in only 1018 succeeding
Nathan Fairchild wrote: When I run a script like so: cat: /u/pe/env_files/transpath.map: No such file or directory ./run_many.sh: fork: retry: Resource temporarily unavailable ./run_many.sh: fork: Resource temporarily unavailable $ grep -l PATH out* | wc -l 1018 I think I'm probably hitting the 256 process limit because of the I/O slowdown the network presents? I don't get this issue running on (much faster) local disk. --- You are only reading from the net? or are you copying to the to the net too? I.e. what is your CWD? is out$i.log on the net or local? I tried it locally and couldn't reproduce your symptoms. Your problem is more likely the server hosting the remote file system. While you can write files locally that fast, the remote server adds enough ms/file delay that it can't keep up. Even processing your Network requests take cpu time. /i/fdlims cat mrun #!/bin/bash ulimit -n 3200 for i in $(seq $1) do exec cat mrun /tmp/tmp$i.log done /i/fdlims ll /tmp/tmp*|wc 4096 28672 191405 --- I'm not sure how accurate the ulimit command inside cygwin is... may be accurate, just saying I don't know. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
what path to use that is not DOS??
I get this message the 1st time logging in via 'rlogin': MS-DOS style path detected: /Windows/System32/cygwin/usr/spool/mail/Bliss/law Preferred POSIX equivalent is: /Windows/System32/cygwin/usr/spool/mail/Bliss/law Can someone explain what is wrong with the 1st that the 2nd corrects? Thanks... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
login -p disabling leads to Windows failures -- as it expects its ENV to remain instact for new processes
Eric Blake wrote: On 10/08/2014 01:55 PM, Linda Walsh wrote: I get this message the 1st time logging in via 'rlogin': You do realize, of course, that rlogin is a security hole, and that you really ought to consider using something more secure like ssh if you are trying to use it outside the boundaries of a heavily-firewalled intranet? http://cc-ipcp.icp.ac.ru/Section1.2.html No, ??? security hole? Depends on your security policy. People cannot talk about rlogin being a security hole -- only in the context of specific usage. /bin/sh is a security hole under the wrong security policy... It's not the program, but how it is used! Don't blame the poor program! ;-) In any event, only local-subnet, non-routable hosts are in the .rhosts. Had problems making localhost work, but might try again I'm trying to use it to login from the same machine into itself. and heavily-firewalled?... um... not exactly, but it isn't on the internet (has to use an http-proxy to get out)... Theoretically, a tunnel could be created through the proxy (http or socks), that could allow someone to run the command to access the local host. or if I ran MS's TCP6 helper that sets up connectivity through firewalls via proxies automatically when you get win7 out of the box (not sure about sp1.. might have made it non-default)... Butthe real problem is login... Corinna corrupted the cygwin version: -p Used by getty(8) to tell login not to destroy the environment. This is disabled in the Cygwin version. --- Thus I log in, but random things fail because standard Windows security environment that windows expects to be there, ISN'T. ...even cygwin uses many of these vars to setup the user's environment. Things like: Path after cygwin clears it: (Note, since windows loads it's libraries via the PATH, Note Windows dirs are not in path: PATH=/Users/law.Bliss/bin/lib:/usr/sbin:.:/prog64/vim:/usr/bin:/sbin:/prog (Normal path using a console window: echo $PATH /Users/law.Bliss/bin/lib:/usr/sbin:.:/prog64/vim:/usr/bin:/sbin:/prog/sysinternals/cmd:/prog/sysinternals:/Windows/system32:/Windows:/Windows/System32/Wbem:/Windows/System32/WindowsPowerShell/v1.0:/Prog/Common Files/DivX Shared:/Prog/NVIDIA Corporation/PhysX/Common:/Prog64/VanDyke Software/Clients:/Prog64/NVIDIA GPU Computing Toolkit/CUDA/v4.0/bin:/Prog/NVIDIA Corporation/Cg/bin:/Prog/NVIDIA Corporation/Cg/bin.x64:/Prog/QuickTime:/Prog/Microsoft SQL Server/110/Tools/Binn:/Prog/Microsoft SQL Server/110/DTS/Binn:/Program Files/Microsoft SQL Server/110/Tools/Binn:/Prog/Microsoft SQL Server/110/DTS/Binn:/Users/law.Bliss/bin:/usr/local/bin:/etc/local/func_lib --- If cygwin wants to clear env and start with an unchanged copy out of the registry, that's fine... but leaving them (there were about 2x more than I list below) out make many programs designed for cygwin (on windows), fail like: bin/dumphive: line 11: USERPROFILE: unbound variable 3564 (process ID) old priority 19, new priority 19 bin/dumphive: line 11: USERPROFILE: unbound variable Root has problems getting any shell: rlogin -l root athenae Password: rlogin: connection closed. rlogin -l Bliss\\root athenae Password: cygwin warning: MS-DOS style path detected: /Windows/System32/cygwin/usr/spool/mail/Bliss/root Preferred POSIX equivalent is: /Windows/System32/cygwin/usr/spool/mail/Bliss/root CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames rlogin: connection closed. --- There's that warning again... missing vars: ALLUSERSPROFILE=C:\ProgramData APPDATA=C:\Users\law.Bliss\AppData\Roaming CLASSPATH=.;C:\Prog\Java\jre7\lib\ext\QTJava.zip;C:\Program Files (x86)\ COMMONPROGRAMFILES=C:\Program Files\Common Files CYGWIN=system nodosfilewarning winsymlinks:native export CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files HISTFILE=/Users/law.Bliss/.histAthenae_cons0 HOMEDRIVE=C: HOMEPATH=\Users\law.Bliss LOCALAPPDATA=C:\Users\law.Bliss\AppData\Local LOGONSERVER=\\ISHTAR OS=Windows_NT PATH=/Users/law.Bliss/bin/lib:/usr/sbin:.:/prog64/vim:/usr/bin:/sbin:/prog PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC PROGRAMFILES=C:\Program Files PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public
bi-arch cygwin (was Re: /usr/local/bin symbolic link disappears every time cyg setup is run)
Dat Head wrote: I have a symlink from /usr/local/bin to /3TB-external/bin/CYGWIN to keep architecture independent bin files on an external drive for portability. I've tried similar and wasn't able to convince anyone (my track record on being convincing is significantly lamer than mosts'). I thought this (https://cygwin.com/ml/cygwin/2014-03/msg00494.html) was the best solution to fix this problem. I first mentioned it in this: (https://cygwin.com/ml/cygwin/2014-01/msg00089.html) post and would love to see it work. As it is, I have to manually recreate the links and manually copy programs installed at the wrong location after each install. Re: solutions to use a cygwin mount point: Kurt Franke wrote: I just use /usr/local as a mount point: $ df /usr/local/ D:/cygwin-local/usr/local 766838780 405249584 361589196 53% /usr/local setup may create any structure under this mount point, but this has no effect in cygwin... and Achim Gratz wrote: Just create a mount in /etc/fstab and keep the tree under the mount point empty. Miss the point -- I want setup to write into the shared location for /usr/share or any specific mount point. Both mountvol and linkd create junctions which are called soft mount points by microsoft vs. mklink, which actually creates something called a symbolic link. Under cygwin, linkd-created junctions are treated like symlinks. I lobbied (unsuccessfully) to get this changed. The stumbling block was a fear of this creating directory loops -- which cygwin already creates via it's own soft mounts (or so find tells me when doing a rebuild of the locate db. The same behaviors happen on linux with it's mount program redirecting files and directories... the device num doesn't change -- and loops can result. But linux took the path of providing the feature and not second-guessing how users and admins should configure their computer. When MS implemented junctions in Win2k, they said that uncareful use could result in directory loops. It is unfortunate that cygwin should have eliminated the usefulness of MS's directory remounting (as this would have kept this feature in parity with linux). every time I run cyg setup.exe it removes the symlink and creates an empty /usr/local/bin directory - is it really supposed to do that? are there some cygwin pkgs (none that I have installed because it has never put anything there) that put files there? (even if there are, it shouldn't zap the symlink) If it doesn't put files in there, then why would it delete the symlink? That seems like a malicious enforcement of a broken paradigm. Note, this allows this type of structure: ll / |grep cyg|cut -c42-999 bin - /windows/system32/cygwin/bin/ bin1 - /windows/system32/cygwin/bin/ cygcommon/ cygwin/ cygwin64/ etc - /Windows/system32/cygwin/etc/ lib - /Windows/System32/cygwin/lib/ sbin - /Windows/System32/cygwin/sbin/ usr - /Windows/System32/cygwin/usr/ var - /Windows/System32/cygwin/var/ Then the link in /windows/system32 is handled by windows: (under 32 bit windows:) C:\cygwin\binuname -a CYGWIN_NT-6.1-WOW64 Athenae 1.7.28(0.271/5/3) 2014-02-09 21:06 i686 Cygwin C:\cygwin\bindir \windows\system32|grep cyg 01/10/2014 01:09 PMSYMLINKD cygwin [C:\cygwin] (64-bit windows:) C:\binuname -a CYGWIN_NT-6.1 Athenae 1.7.32(0.274/5/3) 2014-08-13 23:06 x86_64 Cygwin C:\bindir C:\windows\system32|grep cygwin 01/11/2014 09:21 PMSYMLINKD cygwin [C:\cygwin64] So depending on whether you are running 32-bit or 64-bit, the *redirector* link in /windows/syswow64|system32/ redirects you to the compatible architecture (or should if everything was put together correctly. Unfortunately, w/o any soft-mount support by honoring window's linkd entries, it's not easy to maintain this type of setup (as you can tell from the uname output -- my 32-bit cygwin doesn't get updated as often... ;-( Anyway, just a rehash of what a bi-arch cygwin might look like and how it could be implemented. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: changing cygdrive prefix in fstab has no effect
Have you tried 'mount -h'? It shows an option to change the cygdrive. I've always used that. In regards to the cygdrive prefix I thought the results of changing the prefix with the 'mount' command were recorded in /etc/fstab -- and that it wasn't the source of the direction...? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bash uses lseek while reading from serial device
Being a bit of a busybody... I forwarded this to the bash list and chet responded there... so forwarding it back here... not sure what isatty is supposed to do with a serial line, let alone one on windows... Original Message Subject: Re: Fwd: Bash uses lseek while reading from serial device Date: Sun, 17 Aug 2014 18:12:23 -0400 From: Chet Ramey Organization: ITS, Case Western Reserve University To: Linda Walsh, bug-bash CC: chet.ramey References: 53f041fd.3050...@tlinx.org On 8/17/14, 1:47 AM, Linda Walsh wrote: ?? Could this be a cygwin bug? It's hard to see why cygwin would start using lseek calls when running bash unless bash called them... but then tha's not to say something else entirely may be going on as this is running on Windows... ;-/ The original poster's speculation is correct. Bash is not allowed to read more input from stdin than it actually consumes, so commands that it runs get the intended input. To that end, it tries to detect whether or not the fd it is using for standard input is seekable: if it is, bash assumes that it can correctly position the file pointer by seeking backwards; if it is not, bash reads a character at a time. Bash uses lseek to the current file position to check this. If the lseek returns -1/EPIPE, bash assumes the fd is not seekable. If it returns 0, bash assumes that it can move around freely. Since bash is trying to seek backwards in the file, stdin is either a regular file or a tty (in which case bash assumes that reads are newline-delimited by the device driver). I suspect what happens is that isatty() returns 1 for serial devices, but reads are not newline-delimited. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Withdrawing from the project
Christopher Faylor wrote: I'll be unsubscribing from all cygwin mailing lists right after sending this. I'll likely continue to use Cygwin but just as a user. Dang... you probably won't see all the goodbyes... But in case... best wishes in your new endeavor. Your efforts here were very much appreciated. Linda Walsh -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
problem in newer rsyncs: no xattr support
Somehow in the newer rsyncs (at least 3.1.0 and 3.0.9), xattr support has accidently been disabled. Could this util be respun w/xattrs turned back on? Thanks... rsync --version rsync version 3.1.0 protocol version 31 Copyright (C) 1996-2013 by Andrew Tridgell, Wayne Davison, and others. Web site: http://rsync.samba.org/ Capabilities: 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, no socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace, append, ACLs, no xattrs, iconv, symtimes, prealloc rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details. law.Bliss uname -a CYGWIN_NT-6.1 Athenae 1.7.31(0.272/5/3) 2014-07-25 11:26 x86_64 Cygwin -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The deprecated uid issue: use caps
D. Boland wrote: Linda Walsh wrote: D. Boland wrote: But I had to compromise in some critical areas. One of them is the uid issue. * sendmail, procmail, mail.local assume that the id of the privileged user is '0'. Isn't it about time to make this our First Directive also? I thought sendmail used capabilities? Isn't it about time none of them used a fixed 'uid', but used capabilities? I thought hard coding a Uid was going out with the dodo bird? You didn't get the point. We create a kernel on which Linux software runs. We don't dictate how software should be written. You are missing the point. MS privilege model is the MS version of the linux capability model. MS didn't get it wrong, linux has been slow to adopt, but MS had linux capabilities 10 years before linux did. Several other people have tried to explain that the way to go is to use the minimum priviledge model. For example, almost ALL user have the unreadable directory traversal priv/capability. To enforce it cost alot in execution time on Windows (as it would under cygwin). Another priviledge is to impersonate another user; sendmail would likely need such a privilege. Another is to ignore file-permissions. It would be questionable whether or not sendmail needed that. Sendmail was using capabilities back in 2000 when I brought a basic non-reciprocal action bug in the capability code to the attention of Ted Tso, he told me and others that I didn't know what I was talking about and they were following POSIX and my find was irrelevant under POSIX. About 10 days later there was a day-zero exploit involving the bug in the defective code using sendmail's capability usage as the vector. The result was kernel caps being disabled for the next few years until the cap-code could be reviewed by more eyes and knew what to look for. So I'm pretty sure sendmail has had code to extensively run solely off of capabilities and has had it for some time. I'd be surprised if it was removed. Linux software that uses the capability model is likely to not have these problems. But saying that any random linux software with security bugs from the past should work on cygwin, seems like a ridiculous stance to take. You can set capabilities on files processes and network sockets. Linux file systems with extended attributes or alternate data forks (2 names for the same thing), can and do support SETCAP on linux files that works just like SETUID, but for capabilities. MS only supports the capability model and uses it to implement their Admin or privileged user model. They don't support the less secure setuid model that linux is moving away from. Does this help clarify the issue ? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: The eternal uid issue
D. Boland wrote: But I had to compromise in some critical areas. One of them is the uid issue. * sendmail, procmail, mail.local assume that the id of the privileged user is '0'. Isn't it about time to make this our First Directive also? I thought sendmail used capabilities? Isn't it about time none of them used a fixed 'uid', but used capabilities? I thought hard coding a Uid was going out with the dodo bird? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
