Re: [ITA] ocaml 3.12.0
On 2010-09-09, at 21:07, Andrew Schulman wrote: Auto gold star awarded: http://cygwin.com/goldstars/#DD. Ooooh, shiny! Thanks! And a thanks from me - the OCaml package was way out of date, but I tried once to build it for Cygwin and couldn't make it work. But I'm cheating: I have insider information. -- Damien
Re: [ITA] ocaml 3.12.0
And a thanks from me - the OCaml package was way out of date, but I tried once to build it for Cygwin and couldn't make it work. But I'm cheating: I have insider information. No holds barred here at cygwin.com.
cygwin/X and nVidia nview multiple desktops
Is there any way to get cygwin/X windows to move to another virtual desktop using nView? When I try, the window just remains visible on all desktops. -- 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/
src/winsup/cygwin ChangeLog fhandler_procsys.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-10 08:06:03 Modified files: winsup/cygwin : ChangeLog fhandler_procsys.cc Log message: * fhandler_procsys.cc (fhandler_procsys::exists): Rearrange to handle dangling symlinks correctly. Fix comments. (fhandler_procsys::fill_filebuf): Remove useless comment. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5028r2=1.5029 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_procsys.cc.diff?cvsroot=srcr1=1.2r2=1.3
src/winsup/cygwin ChangeLog security.cc securi ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-10 09:32:13 Modified files: winsup/cygwin : ChangeLog security.cc security.h sec_acl.cc Log message: * security.cc (get_file_sd): Add bool parameter justcreated. Use GetSecurityInfo only if justcreated is true, NtQuerySecurityObject otherwise. Add comment to explain why. Don't waste time to call NtQuerySecurityObject twice, just allocate big enough area. (get_file_attribute): Call get_file_sd with justcreated set to false. (set_file_attribute): Call get_file_sd with justcreated depending on S_JUSTCREATED pseudo file attribute. (check_file_access): Call get_file_sd with justcreated set to false. * sec_acl.cc (setacl): Ditto. (getacl): Ditto. * security.h: Convert many functions to regparm functions. (get_file_sd): Declare with extra bool parameter. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5029r2=1.5030 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/security.cc.diff?cvsroot=srcr1=1.242r2=1.243 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/security.h.diff?cvsroot=srcr1=1.112r2=1.113 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sec_acl.cc.diff?cvsroot=srcr1=1.60r2=1.61
src/winsup/cygwin ChangeLog mount.cc ntdll.h
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-10 10:04:29 Modified files: winsup/cygwin : ChangeLog mount.cc ntdll.h Log message: * mount.cc (class fs_info_cache): New class to cache filesystem information. (fs_info::update): Check FileFsVolumeInformation against filesystem cache and use it, if filesystem is already available. Add filesystem to cache, if not. Only request FileFsObjectIdInformation if FILE_SUPPORTS_OBJECT_IDS is set in filesystem flags. * ntdll.h (struct _FILE_FS_VOLUME_INFORMATION): Add pragma pack so the structure size is matching the OS expectations. Add __dummy member used in filesystem cache. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5030r2=1.5031 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mount.cc.diff?cvsroot=srcr1=1.66r2=1.67 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ntdll.h.diff?cvsroot=srcr1=1.102r2=1.103
src/winsup/cygwin ChangeLog flock.cc sec_acl.c ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-10 14:53:44 Modified files: winsup/cygwin : ChangeLog flock.cc sec_acl.cc security.cc security.h Log message: * flock.cc (allow_others_to_sync): Define MAX_PROCESS_SD_SIZE. Use instead of ACL_DEFAULT_SIZE. * sec_acl.cc (setacl): Use TLS buffer to allow maximum ACL size. * security.h (ACL_DEFAULT_SIZE): Drop definition. (ACL_MAXIMUM_SIZE): Define. (SD_MAXIMUM_SIZE): Define. * security.cc (get_file_sd): Allocate security_decscriptor with size SD_MAXIMUM_SIZE. (alloc_sd): Use TLS buffer to allow maximum ACL size. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5031r2=1.5032 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/flock.cc.diff?cvsroot=srcr1=1.28r2=1.29 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/sec_acl.cc.diff?cvsroot=srcr1=1.61r2=1.62 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/security.cc.diff?cvsroot=srcr1=1.243r2=1.244 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/security.h.diff?cvsroot=srcr1=1.113r2=1.114
src/winsup/cygwin ChangeLog syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-10 18:51:44 Modified files: winsup/cygwin : ChangeLog syscalls.cc Log message: * syscalls.cc (fstatat): Call stat_worker directly from here. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5032r2=1.5033 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.565r2=1.566
src/winsup/cygwin ChangeLog syscalls.cc
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2010-09-10 19:55:26 Modified files: winsup/cygwin : ChangeLog syscalls.cc Log message: * syscalls.cc (rename): Limit retry loop in case of sharing violation to about a second. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5033r2=1.5034 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/syscalls.cc.diff?cvsroot=srcr1=1.566r2=1.567
[PATCH] Add fenv.h and support.
Hi folks,
This patch adds fenv.h and the related support routines in the Cygwin DLL.
It's an entirely unencumbered implementation that I wrote from scratch using
only the public docs for reference. We've been missing this for a while, what
with PR323 and all, and if we add it in we'll be able to switch on the new
decimal-floating-point features in the compiler. (Amongst I'm sure many other
uses).
winsup/cygwin/ChangeLog:
* Makefile.in (DLL_OFILES): Add new fenv.o module.
(fenv_CFLAGS): New flags definition for fenv.o compile.
* autoload.cc (std_dll_init): Use fenv.h functions instead of direct
manipulation of x87 FPU registers.
* crt0.c (mainCRTStartup): Likewise.
* cygwin.din (feclearexcept, fegetexceptflag, feraiseexcept,
fesetexceptflag, fetestexcept, fegetround, fesetround, fegetenv,
feholdexcept, fesetenv, feupdateenv, fegetprec, fesetprec,
feenableexcept, fedisableexcept, fegetexcept, _feinitialise,
_fe_dfl_env, _fe_nomask_env): Export new functions and data items.
* fenv.cc: New file.
* posix.sgml: Update status of newly-implemented APIs.
* include/fenv.h: Likewise related header.
* include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump.
Testing: well, I'm running the GCC testsuite against it to verify it builds
functioning decimal floating point code, and I've manually tested some of the
simple functionality like setting the exceptions on and off. That's all so
far, but I think it's close enough (and given that it's new functionality) to
check in and fix any bugs that crop up on HEAD. (I'd like to also see if I
can run some of the LSB or Posix verification testsuites against it, but I
don't know what's involved in that yet; if anyone has any experience with any
of that stuff, I'd appreciate being dropped a note off-list with a few
pointers.)
cheers,
DaveK
Index: winsup/cygwin/Makefile.in
===
RCS file: /cvs/src/src/winsup/cygwin/Makefile.in,v
retrieving revision 1.238
diff -p -u -r1.238 Makefile.in
--- winsup/cygwin/Makefile.in 6 Sep 2010 09:47:00 - 1.238
+++ winsup/cygwin/Makefile.in 10 Sep 2010 07:07:03 -
@@ -137,7 +137,7 @@ MT_SAFE_OBJECTS:=
#
DLL_OFILES:=assert.o autoload.o bsdlib.o ctype.o cxx.o cygheap.o cygthread.o \
cygtls.o cygxdr.o dcrt0.o debug.o devices.o dir.o dlfcn.o dll_init.o \
- dtable.o environ.o errno.o exceptions.o exec.o external.o fcntl.o \
+ dtable.o environ.o errno.o exceptions.o exec.o external.o fcntl.o fenv.o \
fhandler.o fhandler_clipboard.o fhandler_console.o fhandler_disk_file.o \
fhandler_dsp.o fhandler_fifo.o fhandler_floppy.o fhandler_mailslot.o \
fhandler_mem.o fhandler_netdrive.o fhandler_nodevice.o fhandler_proc.o \
@@ -244,6 +244,7 @@ dlfcn_CFLAGS:=-fomit-frame-pointer
dll_init_CFLAGS:=-fomit-frame-pointer
dtable_CFLAGS:=-fomit-frame-pointer -fcheck-new
fcntl_CFLAGS:=-fomit-frame-pointer
+fenv_CFLAGS:=-fomit-frame-pointer
fhandler_CFLAGS:=-fomit-frame-pointer
fhandler_clipboard_CFLAGS:=-fomit-frame-pointer
fhandler_console_CFLAGS:=-fomit-frame-pointer
Index: winsup/cygwin/autoload.cc
===
RCS file: /cvs/src/src/winsup/cygwin/autoload.cc,v
retrieving revision 1.172
diff -p -u -r1.172 autoload.cc
--- winsup/cygwin/autoload.cc 30 Aug 2010 10:39:43 - 1.172
+++ winsup/cygwin/autoload.cc 10 Sep 2010 07:07:03 -
@@ -11,6 +11,7 @@ details. */
#include winsup.h
#include miscfuncs.h
+#include fenv.h
#define USE_SYS_TYPES_FD_SET
#include winsock2.h
@@ -222,13 +223,13 @@ std_dll_init ()
while (InterlockedIncrement (dll-here));
else if (!dll-handle)
{
- unsigned fpu_control = 0;
- __asm__ __volatile__ (fnstcw %0: =m (fpu_control));
+ fenv_t fpuenv;
+ fegetenv (fpuenv);
/* http://www.microsoft.com/technet/security/advisory/2269637.mspx */
wcpcpy (wcpcpy (dll_path, windows_system_directory), dll-name);
if ((h = LoadLibraryW (dll_path)) != NULL)
{
- __asm__ __volatile__ (fldcw %0: : m (fpu_control));
+ fesetenv (fpuenv);
dll-handle = h;
}
else if (!(func-decoration 1))
Index: winsup/cygwin/crt0.c
===
RCS file: /cvs/src/src/winsup/cygwin/crt0.c,v
retrieving revision 1.5
diff -p -u -r1.5 crt0.c
--- winsup/cygwin/crt0.c 30 Aug 2010 01:57:36 - 1.5
+++ winsup/cygwin/crt0.c 10 Sep 2010 07:07:03 -
@@ -13,11 +13,7 @@ details. */
#include winlean.h
#include sys/cygwin.h
-#ifdef __i386__
-#define FPU_RESERVED 0xF0C0
-#define FPU_DEFAULT 0x033f
-
-#endif
+#include fenv.h
extern int main (int argc, char **argv);
@@ -29,19 +25,7 @@ mainCRTStartup ()
#ifdef __i386__
(void)__builtin_return_address(1);
asm volatile (andl $-16,%%esp ::: %esp);
- {
-volatile unsigned short cw;
-
-/* Get Control Word */
-__asm__
Re: [PATCH] Add fenv.h and support.
On Fri, Sep 10, 2010 at 09:53:28PM +0100, Dave Korn wrote: Hi folks, This patch adds fenv.h and the related support routines in the Cygwin DLL. It's an entirely unencumbered implementation that I wrote from scratch using only the public docs for reference. We've been missing this for a while, what with PR323 and all, and if we add it in we'll be able to switch on the new decimal-floating-point features in the compiler. (Amongst I'm sure many other uses). winsup/cygwin/ChangeLog: * Makefile.in (DLL_OFILES): Add new fenv.o module. (fenv_CFLAGS): New flags definition for fenv.o compile. * autoload.cc (std_dll_init): Use fenv.h functions instead of direct manipulation of x87 FPU registers. * crt0.c (mainCRTStartup): Likewise. * cygwin.din (feclearexcept, fegetexceptflag, feraiseexcept, fesetexceptflag, fetestexcept, fegetround, fesetround, fegetenv, feholdexcept, fesetenv, feupdateenv, fegetprec, fesetprec, feenableexcept, fedisableexcept, fegetexcept, _feinitialise, _fe_dfl_env, _fe_nomask_env): Export new functions and data items. * fenv.cc: New file. * posix.sgml: Update status of newly-implemented APIs. * include/fenv.h: Likewise related header. * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump. Testing: well, I'm running the GCC testsuite against it to verify it builds functioning decimal floating point code, and I've manually tested some of the simple functionality like setting the exceptions on and off. That's all so far, but I think it's close enough (and given that it's new functionality) to check in and fix any bugs that crop up on HEAD. (I'd like to also see if I can run some of the LSB or Posix verification testsuites against it, but I don't know what's involved in that yet; if anyone has any experience with any of that stuff, I'd appreciate being dropped a note off-list with a few pointers.) Looks nice to me with one HUGE caveat: Please maintain the pseudo-sorted order in cygwin.din. Sorry to have to impose this burden on you. Other than that, please check in and thanks for the patch. It was obviously a lot of work. cgf
Re: [PATCH] Add fenv.h and support.
On 10/09/2010 22:43, Christopher Faylor wrote: Looks nice to me with one HUGE caveat: Please maintain the pseudo-sorted order in cygwin.din. Sorry to have to impose this burden on you. No, that's fine; I've never been sure whether we need to care about the ordinal numbers or not in that file. (AFAIK, we don't have any realistic scenarios where anyone would be linking against the Cygwin DLL by ordinal imports, but I hate making assumptions based only on my own limited experience...) Other than that, please check in and thanks for the patch. It was obviously a lot of work. Heh, actually not all that much. I had one of those in-the-zone moments and did both this and the gnu ld plugin infrastructure in one ~20h no-sleep coding binge, then spent another few hours tidying it up after I'd slept a bit! So, I'll fix the cygwin.din and check in shortly. Thanks for reviewing. (BTW, the request for advice re: automated compliance checking stands; I would really like to run some proper formal testsuites against this, even if they don't fully work on Cygwin. Eric, surely you've looked at this stuff? I was certainly hoping so, anyway!) cheers, DaveK
Re: [PATCH] Add fenv.h and support.
On Sat, Sep 11, 2010 at 01:42:49AM +0100, Dave Korn wrote: On 10/09/2010 22:43, Christopher Faylor wrote: Looks nice to me with one HUGE caveat: Please maintain the pseudo-sorted order in cygwin.din. Sorry to have to impose this burden on you. No, that's fine; I've never been sure whether we need to care about the ordinal numbers or not in that file. (AFAIK, we don't have any realistic scenarios where anyone would be linking against the Cygwin DLL by ordinal imports, but I hate making assumptions based only on my own limited experience...) It never even occurred to me about ordinal numbers but since I've been reorganizing that file for years I guess it hasn't been a problem. cgf
Re: Oddities with file deletion on CIFS drive
On Sep 8 15:17, Quanah Gibson-Mount wrote: I have a CIFS drive I connect to as the windows user. I can write to the drive with no problem. However, when I go to delete files from the drive, Cygwin behaves very oddly. bu...@zre-win-002 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates $ rm -f * If you call rm w/o the -f flag, what error message do you get? Just a simple Permission denied, I guess. bu...@zre-win-002 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates $ ls -l total 104 -r-xr-xr-x 1 1362 2010-09-08 13:31 BUILD_EVO_template -r-xr-xr-x 1 1453 2010-09-08 13:31 BUILD_ISYNC_template [...] Now, if I modify the file to be +w, then -w, so it returns to its original permissions, I can suddenly delete it: Did you create the files with a Cygwin aplication or with a native Win32 application? In theory, there's nothing mysterious here, if the permissions of the file are so that the DELETE permission for your user or group is missing in the file's ACL. For obvious reasons the POSIX permission bits can't reflect the complexity of the original NT ACL. The chmod +w/-w somehow overwrite the original permissions with POSIX permissions as Cygwin generates them and the result is more DELETE friendly. Did you try to compare the ACL before and after the chmod? The output of `cacls filename' is probably different. This behavior is quite bizarre. I should be able to delete the files I created with the -f option to rm. Well, in theory, yes. However, it's possible that your CIFS drive has semantics which disallow this with the original ACL for some reason. Can you pleae run `strace -o rm.trace rm some_file' on a file which has the original ACL (before the chmod call) and send the rm.trace file? 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
quick way to find out if a file is in use by windows?
I use the mv command to clean up some directories filled with temporary files. These may or may not be in use by windows. I used to detect them being in use by windows by mv failing. Now, mv is simply taking forever. I'm using cygwin 1.7.7(0.230/5/3), windows 2003 server 32 bits with all updates on a local NTFS disk. I remember reading something about this changing in the last release, but I can't find it in the archives anymore (searching for 'file in use' didn't work out). Is there any way to detect if a file is in use by windows before executing 'mv' (I really, really hope I don't have to use the 'handle.exe' utility, which takes seconds for each file...)? Alternatively, could mv timeout somewhat earlier? I control-C'ed it after 15 minutes, which is really too long already. Thanks, Jurriaan -- You want to save them all, ATerafin? She laughed, and the laugh was chilling. Try, try with my blessings. There was no question whatever to Margret that the words were a curse, meant to cause pain; they implied certain failure, and the amusement of the powerful at the pathetic struggles of those doomed to fail. Michelle West - The Shining Court -- 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
chmod -R 777*
Hello, I use windows XP on a small server. Lately I downloaded a software (hydrological computation) which asked me to install as well ‘cygwin’ and then to perform in cygwin window the command: ‘chmod –R 777 *’ in order to give writings permission and allow the software to perform. I admit, I did not check, this instruction came from serious people….But I started to frick out when I realized that this command did not only change the permission of files related to the software or cygwin, but of all the files on my computer, it even started to process on the content of a dvd that was in my computer and I stopped the process since I was fearing that it would continue to the server’s disks….. I immediately perform a system restore at 1week before, but I am not sure I am OK with the permissions of sensitives windows files. Indeed, the dll files in the windows/system folder show a read/execute and write permission to everyone for example. It might have been like this before the problem with the ‘chmod’, but I can not tell and I worry I did something wrong. Is there any way to check the proper permission configuration on windows XP or to restore it? Any suggestion or help will be very very appreciated. Thanks, Yohann -- 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: quick way to find out if a file is in use by windows?
On Sep 10 11:46, Jurriaan wrote: I use the mv command to clean up some directories filled with temporary files. These may or may not be in use by windows. I used to detect them being in use by windows by mv failing. Now, mv is simply taking forever. I'm using cygwin 1.7.7(0.230/5/3), windows 2003 server 32 bits with all updates on a local NTFS disk. I remember reading something about this changing in the last release, but I can't find it in the archives anymore (searching for 'file in use' didn't work out). Is there any way to detect if a file is in use by windows before executing 'mv' (I really, really hope I don't have to use the 'handle.exe' utility, which takes seconds for each file...)? Alternatively, could mv timeout somewhat earlier? I control-C'ed it after 15 minutes, which is really too long already. mv does not timeout. The underlying unlink function checks if the file is in use and, if so, moves the file to the bin and sets the delete disposition so it will be deleted after the last process closes its handle to the file. If this fails, unlink silently gives up. The reason for the hang must be something else. 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: chmod -R 777*
On 9/10/2010 4:04 AM, Yohann wrote: [snip] Is there any way to check the proper permission configuration on windows XP or to restore it? Windows doesn't care about permissions, it uses 777 for everything, and that is the default (everything has that permission, text, pictures, music, zip archives, ...). You don't need to change it, but if you do, you have to be careful to keep executables with the executable permission, or they won't run. -- René Berber -- 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: Oddities with file deletion on CIFS drive
--On Friday, September 10, 2010 11:16 AM +0200 Corinna Vinschen wrote: On Sep 8 15:17, Quanah Gibson-Mount wrote: I have a CIFS drive I connect to as the windows user. I can write to the drive with no problem. However, when I go to delete files from the drive, Cygwin behaves very oddly. bu...@zre-win-002 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/tem plates $ rm -f * If you call rm w/o the -f flag, what error message do you get? Just a simple Permission denied, I guess. Nope. It doesn't give any error. bu...@zre-win-002 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates $ rm BUILD_ISYNC_template rm: remove write-protected regular file `BUILD_ISYNC_template'? y bu...@zre-win-002 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates $ ls -l BUILD_ISYNC_template -r-xr-xr-x 1 1453 2010-09-08 13:31 BUILD_ISYNC_template bu...@zre-win-002 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/tem plates $ ls -l total 104 -r-xr-xr-x 1 1362 2010-09-08 13:31 BUILD_EVO_template -r-xr-xr-x 1 1453 2010-09-08 13:31 BUILD_ISYNC_template [...] Now, if I modify the file to be +w, then -w, so it returns to its original permissions, I can suddenly delete it: Did you create the files with a Cygwin aplication or with a native Win32 application? In theory, there's nothing mysterious here, if the permissions of the file are so that the DELETE permission for your user or group is missing in the file's ACL. For obvious reasons the POSIX permission bits can't reflect the complexity of the original NT ACL. The chmod +w/-w somehow overwrite the original permissions with POSIX permissions as Cygwin generates them and the result is more DELETE friendly. Did you try to compare the ACL before and after the chmod? The output of `cacls filename' is probably different. The files are created with a native Win32 application (Perforce), where it is checking these files out of the Perforce repository. Here is the output from cacls prior to +w/-w: bu...@zre-win-002 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates $ cacls BUILD_ISYNC_template Z:\current\WINDOWS\main\20100908131458_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template Everyone:F Account Domain not foundF Account Domain not foundR Everyone:R Here is cacls after +w/-w: Z:\current\WINDOWS\main\20100908131458_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template Account Domain not found(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_GENERIC_READ FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_READ_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Account Domain not foundR Everyone:R This behavior is quite bizarre. I should be able to delete the files I created with the -f option to rm. Well, in theory, yes. However, it's possible that your CIFS drive has semantics which disallow this with the original ACL for some reason. Can you pleae run `strace -o rm.trace rm some_file' on a file which has the original ACL (before the chmod call) and send the rm.trace file? Done. I've provided strace output from both rm FILE and rm -f FILE Let me know if there is anything else I can provide. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration rm.trace.gz Description: Binary data rmf.trace.gz Description: Binary data -- 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: Oddities with file deletion on CIFS drive
On Sep 10 09:47, Quanah Gibson-Mount wrote: The files are created with a native Win32 application (Perforce), where it is checking these files out of the Perforce repository. Here is the output from cacls prior to +w/-w: bu...@zre-win-002 /cygdrive/z/current/WINDOWS/main/20100908131458_ZDESKTOP/ZimbraBuild/templates $ cacls BUILD_ISYNC_template Z:\current\WINDOWS\main\20100908131458_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template Everyone:F Account Domain not foundF Account Domain not foundR Everyone:R These permissions look very weird. Here is cacls after +w/-w: Z:\current\WINDOWS\main\20100908131458_ZDESKTOP\ZimbraBuild\templates\BUILD_ISYNC_template Account Domain not found(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_GENERIC_READ FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_READ_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Account Domain not foundR Everyone:R This looks better. The fact that the accounts can't be found is probably because it's running Samba and the drives are not real NTFS, so the SIDs returned by Samba are the artificial SIDs generated from the Unix uid/gid. Btw., just because the Unix user is called build, it's not necessariliy the same user as the Windows user build. Actually, if you don't use Samba with winbind and only use WIndows users from AD on both machines, the accounts are different. Done. I've provided strace output from both rm FILE and rm -f FILE Let me know if there is anything else I can provide. I'm not sure. I don't think so. The problem is that the unlink(2) function in Cygwin does not get any error code from any of the OS functions it calls. So, from the Cygwin POV everything worked fine. How is it supposed to know that anything has gone wrong, if the underlying OS doesn't tell? 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: Oddities with file deletion on CIFS drive
--On Friday, September 10, 2010 7:09 PM +0200 Corinna Vinschen wrote: Let me know if there is anything else I can provide. I'm not sure. I don't think so. The problem is that the unlink(2) function in Cygwin does not get any error code from any of the OS functions it calls. So, from the Cygwin POV everything worked fine. How is it supposed to know that anything has gone wrong, if the underlying OS doesn't tell? Heh, magic I guess. If I mount the drive as a CIFS drive from a Linux box, I can delete the files just fine, so for now that gives me a workaround (I'll move my deletion process to a Linux box). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration Zimbra :: the leader in open source messaging and collaboration -- 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: chmod -R 777*
On 9/10/2010 11:18 AM, René Berber wrote: On 9/10/2010 4:04 AM, Yohann wrote: [snip] Is there any way to check the proper permission configuration on windows XP or to restore it? Windows doesn't care about permissions, it uses 777 for everything, and that is the default (everything has that permission, text, pictures, music, zip archives, ...). You don't need to change it, but if you do, you have to be careful to keep executables with the executable permission, or they won't run. Also dynamic libraries need the executable bits to be used... just ran into that one. Windows sort of cares about permissions, probably that's why the default is 777. -- René Berber -- 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: chmod -R 777*
On Sep 10 12:57, René Berber wrote: On 9/10/2010 11:18 AM, René Berber wrote: On 9/10/2010 4:04 AM, Yohann wrote: [snip] Is there any way to check the proper permission configuration on windows XP or to restore it? Windows doesn't care about permissions, it uses 777 for everything, and that is the default (everything has that permission, text, pictures, music, zip archives, ...). You don't need to change it, but if you do, you have to be careful to keep executables with the executable permission, or they won't run. Also dynamic libraries need the executable bits to be used... just ran into that one. Windows sort of cares about permissions, probably that's why the default is 777. Wll, not exactly. The default permissions are rather 0700, plus an extra 7 for Administrators and SYSTEM. Have a look into your $USERPROFILE directory. Typically only you have full control permissions on your files, Administrators and SYSTEM. But nobody else has any permissions. 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: ***Fatal error couldn't allocate heap win 32 error 487***
On 9/10/2010 3:14 PM, Sridhar Balasubramanian wrote: Hi, For the past few days, i have been facing this particular problem with cygwin:-- I have a perl script to convert .pgm files to .tif file. It used to be working perfectly fine through cygwin bash shell. However, couple of days back it stopped working and throws the following error: Since this is perl-related, I'd say start with perlrebase. -- 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: quick way to find out if a file is in use by windows?
On Sep 10 21:22, jurri...@rivierenland.xs4all.nl wrote: mv does not timeout. The underlying unlink function checks if the file is in use and, if so, moves the file to the bin and sets the delete disposition so it will be deleted after the last process closes its handle to the file. If this fails, unlink silently gives up. The reason for the hang must be something else. Thanks for replying. I straced both mv and rm. The rm strace is at the bottom, below here first the mv strace. It only seems to hang, but the strace is filling up quickly with lots of lines like this continuously: 63 77448 [main] mv 14716 rename: status 0xC043 Is this a status mv should fail on, or is Windows incorrectly returning a status that means 'repeat and retry by all means' ? Oops. I mixed up mv and rm, so my babble about unlink was off the point. Of course mv calls the rename function and the rename function in fact has a loop which retries to rename a file or dir if a sharing violation occurs. The original idea of the retry loop was to workaround a problem with some BLODAs - virus scanners - which block newly generated files against deletion(*) for a short period of time while checking them. This breaks some applications which copy files by creating a temporary filename and then rename the temp filename to the target filename. However, the workaround was missing a break from the loop, if the sharing violation persists. I fixed that in CVS. Thanks, Corinna (*) On Windows a user needs delete permissions to rename a file. -- 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: quick way to find out if a file is in use by windows?
Is there any way to detect if a file is in use by windows before executing 'mv' (I really, really hope I don't have to use the 'handle.exe' utility, which takes seconds for each file...)? fuser 73, Tim Conway JBS USA | 1770 Promontory Ci | Greeley, CO 80634| USA Direct: 970-506-7998 | Fax: 970.336.6195 email: timothy.con...@jbssa.com JBS Server Team -- 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: rm -r removes directory but reports cannot remove 'dir', directory not empty
On Sep 10 19:04, Saurabh T wrote: This is with the latest cygwin and coreutils 8.5-2. Good: mkdir 1; echo $? 0 rm -fr 1; echo $? 0 ls 1 ls: cannot access 1: No such file or directory Bad: mkdir 1; echo $? 0 rm -fr 1; echo $? rm: cannot remove '1': Directory not empty 1 ls 1 ls: cannot access 1: No such file or directory What is that I: drive? What does `mount' print as filesystem type of /cygdrive/i, and what does `/usr/lib/csih/getVolInfo /cygdrive/i' print(*)? I assume I: is not Samba, right? Two problems. - First, the file rename operation in the try_to_bin function fails with STATUS_INVALID_PARAMETER. try_to_bin is only called if a sharing violation occured. Obviously I can't tell where the sharing violation comes from. I assume that the file system on I: returns this error in place of another STATUS_SHARING_VIOLATION. But I don't know. I never saw a STATUS_INVALID_PARAMETER. from the rename function before. The only other problem I can think of is that the filesystem chokes on the 64K buffer size of the FILE_RENAME_INFORMATION buffer. - Second, apparently the actual Directory not empty error is generated artificially by rmdir. There's code which test if the removed directory still exists after the OS call to remove it. This works around a problem in Samba, which sometimes doesn't return an error if the directory can't be removed because it's not empty. For some reason the directory still exists at that point in time, so you get the error. It's not clear to me how to workaround this. At least not as long as we have more info about the filesystem itself. Corinna (*) The getVolInfo tool is part of the csih package. -- 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: quick way to find out if a file is in use by windows?
However, the workaround was missing a break from the loop, if the sharing violation persists. I fixed that in CVS. I do love open source software like this - fixes on a friday night. I'm not sure if I'm ready to use CVS on a production system, but thanks a lot! Kind regards, Jurriaan -- Never use etc. -- it makes people think there is more where there is not or that there is not space to list it all, etc. -- 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: rm -r removes directory but reports cannot remove 'dir', directory not empty
What is that I: drive? What does `mount' print as filesystem type of /cygdrive/i, and what does `/usr/lib/csih/getVolInfo /cygdrive/i' print(*)? I assume I: is not Samba, right? Corinna mount shows: I: on /cygdrive/i type cifs (binary,posix=0,user,noumount,auto) compared to C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) /usr/lib/csih/getVolInfo /cygdrive/ Device Type: 7 Characteristics: 10 Volume Name: build Serial Number : 110167052 Max Filenamelength : 255 Filesystemname : NTFS Flags : 3 FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE I believe I: is Samba (says so in My Computer). Thanks, saurabh -- 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: 1.7.5: Occasional failure of CreatePipe or signal handing due to thread-unsafe code in cwdstuff::set
On Sep 04 02:26 Corinna Vinschen wrote: On Sep 3 16:18, John Carey wrote: On Sep 03 12:37 Corinna Vinschen wrote: On Sep 2 23:32, John Carey wrote: In Aug 17 10:15, Corinna Vinschen wrote: I just released 1.7.6-1. ... What changed since Cygwin 1.7.5: - Cygwin handles the current working directory entirely on its own. The Win32 current working directory is set to an invalid path to be out of the way. This affects calls to the Win32 file API (CreateFile, etc.). See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api Thank you very much for the fix! I've been running tests against Cygwin 1.7.6, and then 1.7.7, and those sporadic, non-deterministic failures in CreatePipe did stop after the 1.7.6 upgrade, and are still gone in 1.7.7. I think it's been long enough to conclude that it is not just the non-determinism--it really is fixed, as expected. I understand that this issue opened a can of worms; thanks again for your efforts to overcome those difficulties. I still don't like the final workaround, which is, to set the Win32 CWD to the Cygwin CWD. It would be nice if we could revert that change to the pre-1.7.6 behaviour in a Vista-friendly way. If you ever find out how to make sure that the new handle in the PEB's user parameter block is used even on Vista and later, pray tell me. Thus far the only ideas I have come up with are somewhat shaky and go well beyond the documented Win32 API. (If only there was the equivalent of dup2(), but for Win32 handles!!!) ACK. Just how much undocumented behavior is tolerable, do you think? Up to XP/2K3, we can simply set the handle in the user parameter block and be done with it, just as in 1.7.5, but without the Vista workaround. The problem only starts with Vista. I have no objections to use undocumented features, if they work. If there's any way to replace the cwd handle with our own *and* keep the Win32 API happy, I'll take it. I think I've found a way to open the directory handle for backup intent on Vista and later versions. Essentially, I emulate the new things that SetCurrentDirectory() is doing, but in order to get the necessary addresses, I have to do some very ugly hacks. The proof-of-concept code follows (and is also attached). It includes an analysis of what is going on--to the extent that I know what is going on, of course. Please let me know what you think. - - - - - - BEGIN INCLUSION - - - - - - - // Compile with Cygwin G++, and include a '-I' argument that // specifies the winsup directory of the Cygwin source tree. // // Run with two arguments: // // 1. An absolute Windows path to a directory (can use forward slashes). // // 2. The relative name of a file within that directory. // // The purpose of this source code is to discuss Win32 CWD // issues and to compile into a proof-of-concept program. // Please read the interleaved comments. #include w32api/include/windows.h #include w32api/include/ntdef.h #include w32api/include/winnt.h #include cygwin/ntdll.h #include algorithm #include cstdlib #include cstring #include iostream #include locale #include string using namespace std; / Primary research was on Windows 7 x64, but there appears to be at least superficial similarity on Windows 2008 (x32 and x64) and Windows Vista (x32 and x64). Let Params be an alias for *NtCurrentTeb ()-Peb-ProcessParameters. Let HeapHandle be an alias for *(PVOID*)((char*)NtCurrentTeb ()-Peb + 0x18) (which is the second 32-bit word after ProcessParameters.) Let DismountCount be an alias for the user space mapping of KUSER_SHARED_DATA::DismountCount: namely, *(ULONG*)0x7ffe02dc. See: http://www.nirsoft.net/kernel_struct/vista/KUSER_SHARED_DATA.html In the implementation of SetCurrentDirectory (), Params.CurrentDirectoryName.MaximumLength is read but NOT modified. Its value determines the sizes of various buffers, including the new buffer that will hold the new current directory pathname. The constant value we have observed for Params.CurrentDirectoryName.MaximumLength is 520, which is sizeof(wchar_t [MAX_PATH]). In addition to the PEB, there is an allocated memory block describing the current directory. Its lifetime is controlled by thread-safe reference counting. Call its type VistaCwd; more details follow. The PEB does NOT seem to point to any VistaCwd instances. Instead, there is a global pointer outside of the PEB, which we call Cwd, and it is protected by a critical section, which we call CwdCS, which is also outside of the PEB. Apparently these globals are in the ntdll.dll data space, but their symbols are not exported. Later we will discuss how to compute their addresses. NOTE: The SetCurrentDirectory () implementation appears to update the Win32 CWD *without* locking the PEB as
Re: setup, upx, and TLS
Yaakov (Cygwin/X) wrote: On Sun, 2010-09-05 at 15:27 -0400, Charles Wilson wrote: Lapo, are you still here? Could we get an updated upx package, please? I'm not so sure that he is still here. Sorry guys, a long strike of too many things to do at the same time had me going a bit in rounds. I've packaged upx (I hope not to have forgot anything of the process ;)), but I fear I'll have the next decently sized time-slot on monday (uh, that'll be a problem to send the announce mesage earlier too). Oh, and I had ready-to-release packages of monotone and tidy, though the first I'm fairly sure it's good, while the latter was copied directly from CygPorts but I didn't really have time to look into the way the package is divided in three and I'd prefer uploading it in a few days (same goes for other packages). http://lapo.it/cygwin/upx/setup.hint http://lapo.it/cygwin/upx/upx-3.07-1-src.tar.bz2 http://lapo.it/cygwin/upx/upx-3.07-1.tar.bz2 http://lapo.it/cygwin/monotone/monotone-0.48-1-src.tar.bz2 http://lapo.it/cygwin/monotone/monotone-0.48-1.tar.bz2 http://lapo.it/cygwin/monotone/setup.hint -- Lapo Luchini - http://lapo.it/ “C is quirky, flawed, and an enormous success.” (Dennis M. Ritchie) -- 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
