Re: [1.7] windows 7 with networked drives - ls failure and mount -c does not stick...
On Oct 20 03:52, Paul J. Ghosh wrote: > r...@nas-01 ~ > # smbd -V > Version 3.0.34 > > r...@nas-01 ~ > # uname -a > Linux nas-01 2.6.17.8ReadyNAS #1 Tue Jun 9 13:59:28 PDT 2009 padre unknown > > > Yes, please go ahead and send a patched dll. The version of smbd is what is > provided in the latest firmware for the Netgear ReadyNas NV+. > http://netgear.com/Products/Storage/ReadyNASNVPlus/RND4000.aspx For the records, the patch helped and I applied it to CVS. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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 package manager
> > On first look, it seems good. Would you consider packaging it as a > Cygwin > > package? You'd get more people using it that way. > > > > If you haven't maintained a Cygwin package before, it wouldn't be > much work > > to get this one going, since it's so simple. I don't think I'd want to > > maintain it, but I'd be glad to help with the initial packaging. > > Thanks for the offer. I'd like to offer it as a package but I have a > question: how stringent is the package submission process? This is an > initial release and will have bugs to iron out. Is there a > minimum-maturity requirement for packages? http://cygwin.com/setup.html#submitting There's no maturity requirement as such. For a package such as cyg-apt that doesn't exist in other distros, you have to get 5 positive votes from current package maintainers. A clear explanation of what cyg-apt does that setup doesn't, would probably go a long way towards that. If you think the software needs more testing before it should go into general release, then you can release it as a "Test" release, as described at the above URL. The disadvantage is that it won't be visible in setup unless people click on the "Test" radio button at the top. You can still ask people on this list to test it. > If you do wish to experiment with using cyg-apt's wider functionality in > an automated context my first thoughts are: > > * run cyg-apt from Windows, rather than inside Cygwin to reduce the > number of packages cyg-apt can't manipulate to the bare minimum (cygwin, > coreutils). See the wiki for more info. Anyone who tries to uninstall Base packages from within Cygwin, gets what they deserve. I suppose though, that you'd run into trouble trying to upgrade Python, or certainly Cygwin, from cyg-apt running in 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: Quantum LTO 4 tape drive and Cygwin 1.7?
On Oct 21 17:51, Corinna Vinschen wrote: > On Oct 21 10:19, Jeffrey C. Smith wrote: > > Also, this is Windows 2008 R2. I'm told that 2008 R2 and Win 7 share the > > same code base. Is 2008 R2 an officially supported platform for 1.7? > > It's supposed to be, though right at the moment I haven't installed > a 2K8 R2 test system, just a W7 x64 system. I'll check that again > in the next couple of days, but the tape ID you have on your system is > not ok. I'd suggest to deinstall the driver, switch off the machine > and reboot. Maybe the next time the tape drive gets a more sensible > ID. If it sticks to this weird ID, I'd file an SRQ at Microsoft. I installed a 2K8 R2 and attached a tape drive. It got the tape ID 0, as expected. Something certainly isn't ok on your machine. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
grep -i --color does not always color
Hi, Is this an error, or have I misunderstod something? /morten $ echo ABCabc|grep --color=auto B ABCabc <<< B is red $ echo ABCabc|grep --color=auto b ABCabc <<< b is red $ echo ABCabc|grep -i --color=auto b ABCabc <<< B and b is red $ echo ABCabc|grep -i --color=auto B ABCabc <<< nothing is red ??? $ echo ABCabc|grep -i --color=always b|od 000 015501 030133 035461 030463 01 045533 015502 066533 020 055433 041513 015541 030133 035461 030463 01 045533 040 015542 066533 055433 061513 12 051 $ echo ABCabc|grep -i --color=always B|od 000 041101 060503 061542 12 007 -- 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: grep -i --color does not always color
2009/10/22 Morten Kjærulff: > Is this an error, or have I misunderstod something? > > /morten > > $ echo ABCabc|grep --color=auto B > ABCabc <<< B is red > > $ echo ABCabc|grep --color=auto b > ABCabc <<< b is red > > $ echo ABCabc|grep -i --color=auto b > ABCabc <<< B and b is red > > $ echo ABCabc|grep -i --color=auto B > ABCabc <<< nothing is red ??? Whatever caused this has been fixed on Cygwin 1.7, where it's working fine. And -- 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 package manager
There's no maturity requirement as such. For a package such as cyg-apt that doesn't exist in other distros, you have to get 5 positive votes from current package maintainers. A clear explanation of what cyg-apt does that setup doesn't, would probably go a long way towards that. Thanks for that, I'll work on the manpage and the case for cyg-apt vs setup. I think they are natural partners actually: setup shows you what's available, and works outside Cygwin, with Cygwin shut down. cyg-apt is strongest when you know what you want and provides package management without closing your Cygwin window. If you think the software needs more testing before it should go into general release, then you can release it as a "Test" release, as described at the above URL. The disadvantage is that it won't be visible in setup unless people click on the "Test" radio button at the top. You can still ask people on this list to test it. Hmmm. If you do wish to experiment with using cyg-apt's wider functionality in an automated context my first thoughts are: * run cyg-apt from Windows, rather than inside Cygwin to reduce the number of packages cyg-apt can't manipulate to the bare minimum (cygwin, coreutils). See the wiki for more info. Anyone who tries to uninstall Base packages from within Cygwin, gets what they deserve. I suppose though, that you'd run into trouble trying to upgrade Python, or certainly Cygwin, from cyg-apt running in Cygwin. What you get is a polite warning that: [python cygwin base-cygwin coreutils bash zlib libreadline] can't be changed from within Cygwin and cyg-apt exits. Cheers, Chris -- 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 package manager
Correction: setup doesn't require Cygwin to be closed if not working on core packages. That makes sense. Chris. -- 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: Quantum LTO 4 tape drive and Cygwin 1.7?
Corinna Vinschen wrote: On Oct 21 17:51, Corinna Vinschen wrote: On Oct 21 10:19, Jeffrey C. Smith wrote: Also, this is Windows 2008 R2. I'm told that 2008 R2 and Win 7 share the same code base. Is 2008 R2 an officially supported platform for 1.7? It's supposed to be, though right at the moment I haven't installed a 2K8 R2 test system, just a W7 x64 system. I'll check that again in the next couple of days, but the tape ID you have on your system is not ok. I'd suggest to deinstall the driver, switch off the machine and reboot. Maybe the next time the tape drive gets a more sensible ID. If it sticks to this weird ID, I'd file an SRQ at Microsoft. I installed a 2K8 R2 and attached a tape drive. It got the tape ID 0, as expected. Something certainly isn't ok on your machine. As you suggested, I removed the driver, updated the firmware, rebooted, and reloaded the driver - no change. Something is definitely wrong with the Win2K box. I've logged a bug with Quantum. We'll see what they say. Thanks much for your help... Jeff -- 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 with libintl-8
Hello all, Before sending me to FAQs etc, I have read probably most of them... And many other mails etc. I was finally able to compile a Linux program of mine for use of my students (the few I didn't convert yet), and, after quite a bit of work, got there. When I run the program from Windows, I get a complaint that 'libintl-8.dll' is not found. It _is_ in \cygwin\bin - just in case, I reinstalled it from setup.exe (Yesterday's version), same luck. Just to be sure, I also reinstalled the entire Cygwin package with the newer setup. Same thing. I don't know how Windows would find the .dll in \cygwin\bin - which is the mechanism? Don't I have to copy the dlls to \window\whatever? Or is there some path coded in the .exe? Help please. John -- 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: How to deny directory-access for one dedicated user
On 10/17/2009 12:04 PM, Dave Korn wrote: Matthias Meyer wrote: How to solve my goal? The user "backup" should backup all data but not certain directories. It cannot be done. Your two requirements amount to: 1- I want the backup user to be able to access all files and directories without restriction. 2- I want the backup user to be restricted from accessing certain files and directories. As a matter of plain logic, these requirements just cannot both be satisfied simultaneously in the same universe! There is no means to give the backup user privileges to access only-some-but-not-all of the files that the ACLs say it should not have access to, because it would essentially require an entire second level of ACLs on every file in the system to keep track of which files the backup privilege gave access to and which files it did not. One point that hasn't been made so far (that I could see) was that while the backup user has access to the entire file system, it is not required that you backup the entire file system if you don't want to. You can always exclude the directories you don't want from your backup operation. This can be done through exclusion lists rather than relying on access permissions. Different functionality for sure bu it will achieve the same end. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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: Problems with libintl-8
On Oct 22 12:53, John Coppens wrote: > I don't know how Windows would find the .dll in \cygwin\bin - which is > the mechanism? Don't I have to copy the dlls to \window\whatever? Or is > there some path coded in the .exe? > > Help please. > John http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Problems with libintl-8
John Coppens wrote: > When I run the program from Windows, I get a complaint that > 'libintl-8.dll' is not found. It _is_ in \cygwin\bin - just in case, I > reinstalled it from setup.exe (Yesterday's version), same luck. Are you sure you copied that error message completely 100% accurately? The filename ought to be "cygintl-8.dll", not "libintl-8.dll". > Just to be sure, I also reinstalled the entire Cygwin package with the > newer setup. Same thing. > > I don't know how Windows would find the .dll in \cygwin\bin - which is > the mechanism? Don't I have to copy the dlls to \window\whatever? Or is > there some path coded in the .exe? The full gory details are at that link in the other reply, but probably the quickest and simplest answer for you is to add the cygwin bin dir to your PATH settings in the windows environment variables. I'm assuming that you're trying to start the program from cmd.exe or by double-clicking in explorer, rather than from a cygwin shell. If you're getting this error when you try and launch the executable from a shell, something else is wrong. cheers, DaveK -- 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: Problems with libintl-8
On Thu, 22 Oct 2009 18:00:08 +0200 Corinna Vinschen wrote: > > Help please. > > John > > http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx Thanks Corinna! I couldn't find any other solution, so I copied cygintl-8.dll to /usr/local/bin (which is where my program installed, and where Windows always looks it seems.). Now the program doesn't complain about the missing dll anymore, but the application window appears and disappears immediately. Maybe something is wrong with the X window install. Cheers, John -- 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: Problems with libintl-8
John Coppens wrote: > When I run the program from Windows, I get a complaint that > 'libintl-8.dll' is not found. It _is_ in \cygwin\bin - just in case, I > reinstalled it from setup.exe (Yesterday's version), same luck. "libintl-8.dll" should NOT be in \cygwin\bin -- and a cygwin-compiled application should not be looking for it. The *cygwin* version of the i18n library is "cygintl-8.dll", which is found in the "libintl8" package. I'm assuming this was simply a typo...if not, then you've somehow picked up a mingw version of the i18n library. > Just to be sure, I also reinstalled the entire Cygwin package with the > newer setup. Same thing. > > I don't know how Windows would find the .dll in \cygwin\bin - which is > the mechanism? Windows uses the following algorithm to find DLLs: 1. look in the same directory as the .exe 2. look in the current directory 3. look in the windows system directory (C:\Windows\system32\) 4. look in the windows directory (C:\Windows) 5. look in each of the directories in the PATH Applications compiled using vis-studio 2005 or newer also can use binary manifests compiled in to the .exe that explicitly specify certain other information used to located DLLs; also, certain registry keys can affect the search path. But the important bits, for you, are items #1 and #5: if you install your exe into C:\cygwin\bin, then it should work. Or, if you set your PATH variable (My Computer->Properties->Advanced System Settings [*]) so that it includes C:\cygwin\bin, that would work also. You could even exploit #2 by creating a Windows Shortcut to your executable, but set the Start In directory of the shortcut to C:\cygwin\bin. > Don't I have to copy the dlls to \window\whatever? No, no, no, a thousand times no! Application programs should never clutter C:\Windows... > Or is there some path coded in the .exe? Not for cygwin (see vis studio note, above). -- Chuck -- 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: Problems with libintl-8
John Coppens wrote: > I couldn't find any other solution, so I copied cygintl-8.dll > to /usr/local/bin (which is where my program installed, and where > Windows always looks it seems.). This is usually a very bad idea. If I release an updated version of cygintl-8.dll (say, with a bugfix but no API change), that would only update the one in C:\cygwin\bin, but you'd still have the old (buggy?) version in /usr/local/bin. This could cause errors and/or confusion. They don't call it DLL Hell for nothing. Changing the PATH, as Corinna suggested, is usually the best approach. NOTE: on Vista the My Computer->Properties->Advanced System Settings approach may not work: that only lets you set: The global system PATH The Administrator user's PATH Instead, for "regular" users, each one should go into Control Panel->User Accounts->Change My Environment Variables. See http://www.question-defense.com/2009/06/22/modify-a-users-path-in-windows-vista-vista-path-environment-variable/ > Now the program doesn't complain about > the missing dll anymore, but the application window appears and disappears > immediately. > > Maybe something is wrong with the X window install. Can't help you, there. -- Chuck -- 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 package manager
Hi there, On Mon, 19 Oct 2009 Chris Cormie wrote: > I am working on a Cygwin package manager with an interface > resembling apt-get. This is the package that I've been dreaming of for years! > It would be great if some folks tried out the initial release and > provided me with some feedback. I'll be glad to give it a test drive, just as soon as I've installed python on all my cygwin boxes. Unfortunately they're all at remote sites, and some of them are _very_ remote... Thanks! -- 73, Ged. -- 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 crontab question
On 10/21/2009 02:14 PM, Larry W. Virden wrote: I now have access to a Cygwin 1.7 installation. I've been trying things out and I am having a spot of trouble that I hope someone can help me through. ... Um, when are you actually going to start a new thread rather than hijacking others? This is the third time that you've replied to a message on the list, either yours or someone else's, changed the subject, and sent your response (new message). This is not creating a new thread. This is hijacking existing ones and it makes following yours and the threads you hijack difficult to follow for those who use threading to organize their email. And it messes up the archives in a similar way. Please, send a new email message to the list with a new subject when you're not just replying to a thread already in progress. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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
Python throws error when closing /dev/urandom
Hi,
I'm not sure if this is the right place to post such problems, but I ran into
this problem when trying to use the paramiko library with python 2.5.2 in
Cygwin.
Ultimately the problem is that an IOError is generated when opening
/dev/urandom, reading some bytes from it (doesn't seem to matter how much),
and closing the file. If you don't read from the file there is no error upon
closing.
$ python
Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14)
[GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
.>>> f = open("/dev/urandom")
.>>> f.close()
Note: no problem just opening and closing the special file. But:
.>>> f = open("/dev/urandom")
.>>> f.read(8)
'\xf9"\xb7\'E\xf8Q\xa0'
.>>> f.close()
Traceback (most recent call last):
File "", line 1, in
IOError: [Errno 0] Error
.>>>
This problem manifests itself when trying to use the paramiko library in
any way:
.>>> import paramiko
Traceback (most recent call last):
File "", line 1, in
File "__init__.py", line 69, in
File "transport.py", line 32, in
File "util.py", line 31, in
File "common.py", line 101, in
File "rng.py", line 69, in __init__
File "randpool.py", line 87, in __init__
File "randpool.py", line 120, in _randomize
IOError: [Errno 0] Error
This error ultimately comes from
/usr/lib/python2.5/site-packages/Crypto/Util/randpool.py, line 118, which I
believe I got from python-crypto 2.0.1-1.
This bug was previously noticed at least a year ago:
http://www.cygwin.com/ml/cygwin/2008-09/msg00561.html (and others)
The suggested work-around, for users of python-crypto, was to change the line
just below this in randpool.py from:
except IOError, (num, msg):
if num!=2: raise IOError, (num, msg)
to
except IOError, (num, msg):
if num!=2 and num!=0: raise IOError, (num, msg)
There was some concern about the validity of this fix but it seems to me that
random data is being pulled from /dev/urandom just fine. But still it would be
nice to attack this problem at the root.
It seems likely that this problem is not reproduced on all systems since, after
all, paramiko is distributed in Cygwin and yet I cannot even import the module.
I'm not sure what else I should detail about my system. It's running Vista SP1.
--
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: Python throws error when closing /dev/urandom
2009/10/22 Topher Cawlfield
> I'm not sure if this is the right place to post such problems, but I ran into
> this problem when trying to use the paramiko library with python 2.5.2 in
> Cygwin.
>
> Ultimately the problem is that an IOError is generated when opening
> /dev/urandom, reading some bytes from it (doesn't seem to matter how much),
> and closing the file. If you don't read from the file there is no error upon
> closing.
>
> $ python
> Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14)
> [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
> Type "help", "copyright", "credits" or "license" for more information.
> .>>> f = open("/dev/urandom")
> .>>> f.close()
>
> Note: no problem just opening and closing the special file. But:
>
> .>>> f = open("/dev/urandom")
> .>>> f.read(8)
> '\xf9"\xb7\'E\xf8Q\xa0'
> .>>> f.close()
> Traceback (most recent call last):
> File "", line 1, in
> IOError: [Errno 0] Error
> .>>>
Reproduced the issue with this C test:
#include
#include
int main(void) {
FILE *f = fopen("/dev/urandom", "r");
if (!f) {
puts("fopen failed");
return 1;
}
char buf[8];
printf("read %i bytes\n", fread(buf, 1, sizeof buf, f));
if (fclose(f)) {
puts("fclose failed");
return 1;
}
return 0;
}
The fclose fails on Cygwin, but succeeds on Debian.
Andy
--
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: Python throws error when closing /dev/urandom
> 2009/10/22 Topher Cawlfield
>> I'm not sure if this is the right place to post such problems, but I ran into
>> this problem when trying to use the paramiko library with python 2.5.2 in
>> Cygwin.
>>
>> Ultimately the problem is that an IOError is generated when opening
>> /dev/urandom, reading some bytes from it (doesn't seem to matter how much),
>> and closing the file. If you don't read from the file there is no error upon
>> closing.
>>
>> $ python
>> Python 2.5.2 (r252:60911, Dec 2 2008, 09:26:14)
>> [GCC 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)] on cygwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> .>>> f = open("/dev/urandom")
>> .>>> f.close()
>>
>> Note: no problem just opening and closing the special file. But:
>>
>> .>>> f = open("/dev/urandom")
>> .>>> f.read(8)
>> '\xf9"\xb7\'E\xf8Q\xa0'
>> .>>> f.close()
>> Traceback (most recent call last):
>> File "", line 1, in
>> IOError: [Errno 0] Error
>> .>>>
>
> Reproduced the issue with this C test:
>
> #include
> #include
>
> int main(void) {
> FILE *f = fopen("/dev/urandom", "r");
> if (!f) {
> puts("fopen failed");
> return 1;
> }
> char buf[8];
> printf("read %i bytes\n", fread(buf, 1, sizeof buf, f));
> if (fclose(f)) {
> puts("fclose failed");
> return 1;
> }
> return 0;
> }
>
> The fclose fails on Cygwin, but succeeds on Debian.
ps: Same issue with /dev/zero, /dev/full, and also /dev/clipboard.
--
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
default ACLs
Hi All Default ACLs don't seem to work as they would on Linux, or for that matter as they do for files created via Windows Explorer. Is this expected? administra...@hostname:/ $ mkdir newdir administra...@hostname:/ $ getfacl newdir # file: newdir # owner: Administrator # group: None user::rwx group::r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:other:r-x administra...@hostname:/ $ setfacl -m 'd:g:dbas:rwx,d:g:SYSTEM:rwx' newdir administra...@hostname:/ $ getfacl newdir # file: newdir # owner: Administrator # group: None user::rwx group::r-x mask:rwx other:r-x default:user::rwx default:group::r-x default:group:SYSTEM:rwx default:group:dbas:rwx default:mask:rwx default:other:r-x administra...@hostname:/ $ touch newdir/newfile administra...@hostname:/ $ getfacl newdir/newfile # file: newdir/newfile # owner: Administrator # group: None user::rw- group::r-- mask:rwx other:r-- Irrespective of CYGWIN=(null), CYGWIN=ntsec, or CYGWIN=nontsec. If I create a file in Windows Explorer, its ACLs are: $ getfacl newdir/newfile2 # file: newdir/newfile2 # owner: Administrators # group: None user::rwx group::r-x group:SYSTEM:rwx group:Users:r-x group:dbas:rwx mask:rwx other:r-x Basically I'm looking for a way to ensure the right users and groups can read files that I create. Thanks Mikel -- 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: gawk Has Problem With CRLF in Mixed Binary/Text Files
I don't have an answer to your specific problem. But as a side issue, I see that your PATH is very long. You might consider using a lot of hard links say in a directory /lbin with a buch of hard links to the real executables in other directories. You can then shorten PATH and remove those duplicate directories. Just be sure that /bin:/lbin is in PATH. The hard links would have to be recreated if you perform any upgrades to some things. Hard links works outside of cygwin since they are implemented at the MS filesystem level. Cygwin symbolic links are different from MS symbolic links. Choose wisely. Reminder: hard links can't cross FS boundaries P.A.Long wrote: t.a.n.s.t.a.a@comcast.net wrote: Hello! I am using a gawk script on files that contain both printing characters and binary data. Gawk is used to modify a few of the printing characters, and I expected that the binary data should be left alone. For the most part, it is, but upon occasion a CRLF will appear inside some of the binary data. All my mounts are binary (see cygcheck.srv, which is from my laptop), but as can be seen by the attached files, the downloaded *** snip *** sigh ... didn't get 'cygcheck.srv' attached; sorry about that! Thx, Phil Long << File: cygcheck.srv >> -- 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: gawk Has Problem With CRLF in Mixed Binary/Text Files
Paul McFerrin wrote: I don't have an answer to your specific problem. But as a side issue, I see that your PATH is very long. You might consider using a lot of hard links say in a directory /lbin with a buch of hard links to the real executables in other directories. You can then shorten PATH and remove those duplicate directories. Just be sure that /bin:/lbin is in PATH. The hard links would have to be recreated if you perform any upgrades to some things. Hard links works outside of cygwin since they are implemented at the MS filesystem level. Cygwin symbolic links are different from MS symbolic links. Choose wisely. Reminder: hard links can't cross FS boundaries ***snip*** -- 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 Paul: I didn't make that path; our IT department and Cygwin setup did. I never have figured out why I get duplicates of everything; perhaps it's due to some weird interaction between my mounts and our Corporate 'client' (it lives down in the kernel, I've heard). And I love the way the path with double-quotes around it doesn't get handled right (I almost alway use Cygwin ZIP, not PKZipW); paths in double-quotes with embedded spaces have been mis-handled that way for a long time. I used to have a gawk script that took care of that, but I haven't bothered with in for years now. In any case, until I get all my machines at work moved over to 1.7 from 1.5, things like that will have to wait. What with layoffs and all, help is rather scarce, and there's lots of other stuff to do. :-/ Thx, Phil Long -- 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: Re: gawk Has Problem With CRLF in Mixed Binary/Text Files
Dave Korn wrote:
t.a.n.s.t.a.a.f.l@ wrote:
[ ... ] but as can be seen by the attached files, the downloaded
gawk executable always changes CRLF to LF,
Is this what you're looking for?
File: gawk.info, Node: User-modified, Next: Auto-set, Up: Built-in Variables
6.5.1 Built-in Variables That Control `awk'
---
[ ... snip ... ]
`BINMODE #'
On non-POSIX systems, this variable specifies use of binary mode
for all I/O. Numeric values of one, two, or three specify that
[ ... snip ... ]
but `gawk' generates a warning message. `BINMODE' is described in
more detail in *note PC Using::.
[ ... snip ... ]
Or this?
File: gawk.info, Node: PC Using, Next: Cygwin, Prev: PC Dynamic, Up: PC Ins\
tallation
B.3.3.4 Using `gawk' on PC Operating Systems
[ ... snip ... ]
Under OS/2 and DOS, `gawk' (and many other text programs) silently
translate end-of-line `"\r\n"' to `"\n"' on input and `"\n"' to
`"\r\n"' on output. A special `BINMODE' variable allows control over
these translations and is interpreted as follows:
[ ... continues ... ]
cheers,
DaveK
Dave:
Didn't work (see attached file). Of course, I could have set BINMODE
the wrong way, but I used the -v method to make sure that it got set
before the BEGIN action. If U see anything wrong with what I've done,
please tell me; I'm not too proud to admit silly mistakes!
And speaking of silly mistakes, I should have looked at the manpage for
gawk *and* at the documentation for Cygwin before I posted; I'll do that
tomorrow. I'll post anything I find; in the meantime, at the suggestion
of David Dyck, I'll be running a2p on my gawk script and using perl instead.
Thx, Phil Long
<< File: cygwinGawk-withBINMODEset.stillNotWorking >>
/work>
/work>
/work>
/work> gawk 'BEGIN{print BINMODE}' BINMODE=3 # just
pressed
0
/work> gawk -v BINMODE=3 'BEGIN{print BINMODE};END{print BINMODE}' # pressed
C-d
3
3
/work> echo -en "\r\n\r\n\n\r"
| xxd -g 1 -u # UH-oh!
000: 31 31 31 31 0D 32 32 32 32 0A 33 33 33 33 0D 0A ....
010: 34 34 34 34 0A 0D 35 35 35 35..
/work> echo -en "\r\n\r\n\n\r" | gawk -v BINMODE=3 '//'
{O,}RS="" | xxd -g 1 -u
000: 31 31 31 31 0D 32 32 32 32 0A 33 33 33 33 0D 0A ....
010: 34 34 34 34 0A 0D 35 35 35 35 78 78 78 78..
/work> echo -en "\r\n\r\n\n\r" | gawk -v BINMODE=3 '//'
{O,}RS="\r\n" | xxd -g 1 -u
000: 31 31 31 31 0D 32 32 32 32 0A 33 33 33 33 0D 0A ....
010: 34 34 34 34 0A 0D 35 35 35 35 0D 0A ....
/work> echo -en "\r\n\r\n\n\r" | gawk -v BINMODE=3 '//'
{O,}RS="\n\r" | xxd -g 1 -u
000: 31 31 31 31 0D 32 32 32 32 0A 33 33 33 33 0D 0A ....
010: 34 34 34 34 0A 0D 35 35 35 35 0A 0D ....
/work> echo -en "\r\n\r\n\n\r" | gawk -v BINMODE=3 '//'
{O,}RS="\r" | xxd -g 1 -u
000: 31 31 31 31 0D 32 32 32 32 0A 33 33 33 33 0D 0A ....
010: 34 34 34 34 0A 0D 35 35 35 35 0D ...
/work> echo -en "\r\n\r\n\n\r" | gawk -v BINMODE=3 '//'
{O,}RS="\n" | xxd -g 1 -u
000: 31 31 31 31 0D 32 32 32 32 0A 33 33 33 33 0D 0A ....
010: 34 34 34 34 0A 0D 35 35 35 35 0A ...
/work>
/work>
/work>
--
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: gawk Has Problem With CRLF in Mixed Binary/Text Files
P.A.Long wrote: Dave Korn wrote: t.a.n.s.t.a.a.f.l@ wrote: [ ... ] but as can be seen by the attached files, the downloaded gawk executable always changes CRLF to LF, Is this what you're looking for? ***snip*** [ ... continues ... ] cheers, DaveK Dave: Didn't work (see attached file). Of course, I could have set BINMODE the wrong way, but I used the -v method to make sure that it got set before the BEGIN action. If U see anything wrong with what I've done, please tell me; I'm not too proud to admit silly mistakes! And speaking of silly mistakes, I should have looked at the manpage for gawk *and* at the documentation for Cygwin before I posted; I'll do that tomorrow. I'll post anything I find; in the meantime, at the suggestion of David Dyck, I'll be running a2p on my gawk script and using perl instead. Thx, Phil Long << File: cygwinGawk-withBINMODEset.stillNotWorking >> Dave: Sigh ... boy, is my face red; I didn't look close enough at my output. I guess it's always a better idea to check the message *before* U send it then after. Thx, Phil Long -- 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 link-dest not working for a host with the most recent rsync/cygwin 1.7
Chris Francy wrote: > First things first, I have narrowed it down and learned something that > resolves the issue for what I am trying to do. > > For versions of rsync before 2.5.6 you could not use the link-dest > reliably unless you copy the permissions/ownership information. With > newer versions of rsync this is not necessary. Glad you were able to figure out a work-around. And it's good to know what worked for you, for future reference. ... > So to demonstrate the link-dest function on my linux box here is a > simple example using relative directories including the output on my > backup server (debian linux 5.0) (http://pastebin.com/m191da91f). > > I have a test case (http://pastebin.com/m6797debc) that I ran against > both two of my systems to demonstrate the difference in behavior. > > Here (http://pastebin.com/m77f9f3b6) is my output when I run the > command on my backup server to get the stuff off my 1.5 host. > > Here (http://pastebin.com/m29252e) is my output when I run the command > on my backup server to get the stuff off my 1.7 host. In this case > the test file in the two destination directories are not hard linked > together like in the 1.5 case. I also noticed that in the the uid/gid > is set differently compared to the 1.5 system. > > So it appears something about permissions isn't coming across the same > as it was on cygwin 1.5. Likely. But that doesn't really answer the question of *why* link-dest is failing to work properly when ownerships and perms are preserved. Even if Cygwin-1.7's rsync is sending bollixed up uid/gid/perms to Debian's rsync, link-dest on the Debian side should still work. Since link-dest is not working, I infer that either: (1) For any given unchanged file, Cygwin-1.7's rsync reports a different set of uid/gid/perms values every time it runs. OR (2) Debian's rsync is unable to faithfully preserve the uid/gid/perms values of files previously saved from Cygwin-1.7's rsync, so that every time such a backup is run, Debian rsync sees the uid/gid/perms as changed. I don't think (1) is at all likely, simply because I can't imagine how such a bug would go undetected for so long. My hypothesis is the problem could be (2). > Since I don't care about the retaining the > permissions, and I now have a version of rsync on both sides that > allows me to use link-dest without copying permissions I am happy. If > someone wants to continue digging into this further I am still > available. Thanks in advance for indulging me just a little bit further. Could you re-run your Cygwin-1.7 test case with --itemize-changes added to the rsync command-line? That should provide a hint at what Debian's rsync thinks is different between its existing file copy and Cygwin's source file. Also, I would like to see what Cygwin's 'stat' command says about the source file on the Windows box. -SM -- -- 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
Novice's stack dump interpretation issues
MAIN QUESTION: I can't seem to find any reference to my functions in the stack dump. The range of function addresses in the stack dump is 0x61002F32-0x7C802542 and yet my functions should be somewhere in the 0x00401000-0x004040A5 range (according to objdump and nm). Is this due to the "Error while dumping state"? How can the error be resolved? MINOR QUESTIONS (feel free to ignore): This is my first time looking at a stack dump (only some limited micro-controller assembly experience from many years ago). Am I correct that the "Function" column represents the logical/virtual return address of the next instruction of the function in memory? Am I correct that the "Frame" column represents the logical/virtual address of the function call in the stack? OFF TOPIC QUESTIONS (feel free to ignore): How useful could a stack dump be for diagnostic purposes with functions of dynamically loaded shared libraries (via. dlsym)? Couldn't the function address be potentially different every time the program was executed? REFERENCES: $ objdump -S Main.exe Main.exe: file format pei-i386 Disassembly of section .text: 00401000 <_WinMainCRTStartup>: 401000:55 push %ebp [... 6907 lines ..] 004040a0 <__DTOR_LIST__>: 4040a0:ff (bad) 4040a1:ff (bad) 4040a2:ff (bad) 4040a3:ff 00incl (%eax) 4040a5:00 00add%al,(%eax) ... $ nm -v Main.exe [... 33 lines ...] 0020 A __size_of_stack_reserve__ 0040 A ___ImageBase 0040 A __image_base__ 00401000 t .text 00401000 T _WinMainCRTStartup [... 98 lines .] 00404098 t .text 00404098 T __CTOR_LIST__ 00404098 T ___CTOR_LIST__ 004040a0 T __DTOR_LIST__ 004040a0 T ___DTOR_LIST__ [... 182 lines of irrelevant symbols .] $ cat Main.exe.stackdump Stack trace: Frame Function Args 0022C8C8 7C802542 (07CC, EA60, 00A4, 0022C910) 0022C9E8 61097F54 (, 7C802600, 7C802542, 00A4) 0022CAD8 61095AEB (, 003B0023, 0023, 0022CE68) 0022CB38 61095FCB (0022CB50, , 0094, 61020C1B) 0022CBF8 61096182 (0C54, 0006, 0022CC28, 61096383) 0022CC08 610961AC (0006, 0022CE88, 28D1, 6109A7DF) 0022CC28 61096383 (6110D008, 00405007, 00405000, 0008) 0022CC58 61001087 (00405000, 0008, 00405007, 00401065) 0022CCE8 610935A8 (0001, 6116B6F0, 00660090, 0022CC70) 0022CD98 610060D8 (, 0022CDD0, 61005450, 0022CDD0) 61005450 61004416 (009C, A02404C7, E8611021, FF48) Exception: STATUS_ACCESS_VIOLATION at eip=61016583 eax=EC815356 ebx=61108148 ecx= edx=57E58959 esi=000B edi=0001 ebp=0065C8B8 esp=0065C8B0 program=c:\[...]\Main.exe, pid 3156, thread sig cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0065C8B8 61016583 (61108148, 6111C19B, FF48, ) 0065C8D8 610166EC (0001, , , 0065C960) 0065C918 61017FD5 (07BC, 0065C960, , ) 0065CC58 61018638 (0744, 0065CC90, 00A4, 0065CC8C) 0065CD58 61099F57 (61106F00, , , ) 0065CD88 61002F32 (0065CE64, 61018970, 1074, ) 61003650 61003769 (04A16430, 8900, FFDA90B0, 24468BFF) 5 [sig] Main 3156 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) -- 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
