Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Dec 17 17:01, Corinna Vinschen wrote: On Dec 17 10:52, Christopher Faylor wrote: On Thu, Dec 17, 2009 at 02:12:15PM +0100, Corinna Vinschen wrote: On Dec 16 13:40, Christopher Faylor wrote: On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote: But we discussed this on the developers list. The old setup will be setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather puzzled that you want to change this again. I have matching local changes to the web page waiting. Please don't change this again. Since I have to change source code to understand the release-legacy directory, I opted to just do it in the trunk rather than the ancient setup 1.5 branch. There will still be a setup-legacy binary. Ok. The problem is just this. If setup.exe still works for 9x users and just access setup-legacy.ini, they will never see that they are accessing an unsupported repository. That's why I now think that setup.exe should give them a warning instead. They should explicitely be forced to use setup-legacy.exe if they updated at all. There will still be a setup-legacy binary != setup.exe will seem to work just fine for Windows 9x users. You wrote that you would like setup to work on 9x again and that's what I'm talking about. I didn't mean to imply anything about setup-legacy. It's all about setup. Details might be helpful. Is there a chance we can release 1.7.1 before Christmas? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]
On Dec 17 01:33, Dave Korn wrote: I think the strace suggests where the problem lies: 350 519655 [main] bash 680 open: 3 = open (/tmp/sh-thd-1261038922, 0x10E01) [ ... snip ... ] 517 535090 [main] bash 680 open: 4 = open (/tmp/sh-thd-1261038922, 0x1) 454 535544 [main] bash 680 close: close (3) 476 536020 [main] bash 680 fhandler_base::close: closing '/tmp/sh-thd-1261038922' handle 0x6A4 679 536699 [main] bash 680 close: 0 = close (3) 563 537262 [main] bash 680 normalize_posix_path: src /tmp/sh-thd-1261038922 605 537867 [main] bash 680 normalize_posix_path: /tmp/sh-thd-1261038922 = normalize_posix_path (/tmp/sh-thd-1261038922) 449 538316 [main] bash 680 mount_info::conv_to_win32_path: conv_to_win32_path (/tmp/sh-thd-1261038922) 571 538887 [main] bash 680 set_flags: flags: binary (0x2) 806 539693 [main] bash 680 mount_info::conv_to_win32_path: src_path /tmp/sh-thd-1261038922, dst Z:\cygremotewin2\tmp\sh-thd-1261038922, flags 0x3000A, rc 0 1641 541334 [main] bash 680 symlink_info::check: not a symlink 1003 542337 [main] bash 680 symlink_info::check: 0 = symlink.check (Z:\cygremotewin2\tmp\sh-thd-1261038922, 0x22B5E8) (0x3000A) 466 542803 [main] bash 680 path_conv::check: this-path(Z:\cygremotewin2\tmp\sh-thd-1261038922), has_acls(1) 547 543350 [main] bash 680 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.7.0-62/winsup/cygwin/syscalls.cc:674 windows error 32 496 543846 [main] bash 680 geterrno_from_win_error: windows error 32 == errno 16 449 544295 [main] bash 680 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):319 val 16 433 544728 [main] bash 680 unlink: -1 = unlink (/tmp/sh-thd-1261038922) 740 545468 [main] bash 680 close: close (4) 498 545966 [main] bash 680 fhandler_base::close: closing '/tmp/sh-thd-1261038922' handle 0x6A0 1121 547087 [main] bash 680 close: 0 = close (4) It looks like the unlink-while-you-still-have-an-open-handle-to-the-file trick isn't working on SMB mounts, perhaps? Indeed. unlink-while-you-still-have-an-open-handle-to-the-file requires to be able to move the file to the recycle bin. The recycle bin does not exist on shares. So you get an EBUSY which is perfectly fine with POSIX. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Dec 16 13:40, Christopher Faylor wrote: On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote: But we discussed this on the developers list. The old setup will be setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather puzzled that you want to change this again. I have matching local changes to the web page waiting. Please don't change this again. Since I have to change source code to understand the release-legacy directory, I opted to just do it in the trunk rather than the ancient setup 1.5 branch. There will still be a setup-legacy binary. Ok. The problem is just this. If setup.exe still works for 9x users and just access setup-legacy.ini, they will never see that they are accessing an unsupported repository. That's why I now think that setup.exe should give them a warning instead. They should explicitely be forced to use setup-legacy.exe if they updated at all. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Thu, Dec 17, 2009 at 02:12:15PM +0100, Corinna Vinschen wrote: On Dec 16 13:40, Christopher Faylor wrote: On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote: But we discussed this on the developers list. The old setup will be setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather puzzled that you want to change this again. I have matching local changes to the web page waiting. Please don't change this again. Since I have to change source code to understand the release-legacy directory, I opted to just do it in the trunk rather than the ancient setup 1.5 branch. There will still be a setup-legacy binary. Ok. The problem is just this. If setup.exe still works for 9x users and just access setup-legacy.ini, they will never see that they are accessing an unsupported repository. That's why I now think that setup.exe should give them a warning instead. They should explicitely be forced to use setup-legacy.exe if they updated at all. There will still be a setup-legacy binary != setup.exe will seem to work just fine for Windows 9x users. cgf
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Dec 17 10:52, Christopher Faylor wrote: On Thu, Dec 17, 2009 at 02:12:15PM +0100, Corinna Vinschen wrote: On Dec 16 13:40, Christopher Faylor wrote: On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote: But we discussed this on the developers list. The old setup will be setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather puzzled that you want to change this again. I have matching local changes to the web page waiting. Please don't change this again. Since I have to change source code to understand the release-legacy directory, I opted to just do it in the trunk rather than the ancient setup 1.5 branch. There will still be a setup-legacy binary. Ok. The problem is just this. If setup.exe still works for 9x users and just access setup-legacy.ini, they will never see that they are accessing an unsupported repository. That's why I now think that setup.exe should give them a warning instead. They should explicitely be forced to use setup-legacy.exe if they updated at all. There will still be a setup-legacy binary != setup.exe will seem to work just fine for Windows 9x users. You wrote that you would like setup to work on 9x again and that's what I'm talking about. I didn't mean to imply anything about setup-legacy. It's all about setup. Details might be helpful. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
Hi Chris, On Dec 13 19:23, c...@sourceware.org wrote: CVSROOT: /cvs/cygwin-apps Module name: setup Changes by: c...@sourceware.org 2009-12-13 19:23:43 Modified files: . : ChangeLog IniDBBuilder.h IniDBBuilderPackage.cc IniDBBuilderPackage.h PickPackageLine.cc PickView.cc install.cc package_meta.cc prereq.cc package_version.cc package_version.h package_meta.h inilex.ll iniparse.yy Log message: * IniDBBuilder.h (buildMessage): Define for base class. * IniDBBuilderPackage.cc (IniDBBuilderPackage::buildMessage): Define. * IniDBBuilderPackage.h (IniDBBuilderPackage::buildMessage): Declare. * PickPackageLine.cc: Pass pointer to package to pick throughout, where appropriate. * PickView.cc: Ditto. * install.cc: Ditto. * package_meta.cc: Ditto. * prereq.cc: Ditto. * package_version.cc: Ditto. (packageversion::pick): Add pkg pointer as second argument. Display message where appropriate. * package_version.h (packageversion::pick): Add pkg pointer as second argument. * package_meta.h (packagemeta::mesage): Define. (packagemeta::set_message): Define. * inilex.ll: Properly return MESSAGE token. * iniparse.yy: Handle message: keyword. This patch seems to be incomplete. Trying to build setup now results in an error: In file included from choose.h:21, from choose.cc:51: package_meta.h:27:29: package_message.h: No such file or directory In file included from choose.h:21, from choose.cc:51: package_meta.h:146: error: `packagemessage' does not name a type package_meta.h: In member function `void packagemeta::set_message(const std::string, const std::string)': package_meta.h:91: error: `message' undeclared (first use this function) package_meta.h:91: error: (Each undeclared identifier is reported only once for each function it appears in.) make[2]: *** [choose.o] Error 1 There's actually no package_message.h file in the repository. Could you please check it in? Btw., is setup finished for the 1.7.1 release with this patch or is there more to come? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]
Corinna Vinschen wrote: Btw., is setup finished for the 1.7.1 release with this patch or is there more to come? Can't speak for cgf, but from my side, I've got all my new features done. I just discovered YA loop-retrying-forever-in-unattended mode bug, which I'll spin up a patch for shortly, but I don't think it's terribly critical as it'll only happen if there's a corrupt mirror, which is an uncommon enough occurrence. Also I think it would be nice if we could figure out what's going on with Thomas' network install in the time remaining, but I don't think we should delay the release any for it. I gave it a try and produced an oddity, although possibly just as an artifact of the way I did it: instead of creating a share, I mapped the default admin //sever/I$ share of my main PC as Z: over SMB from inside a VM and installed it to that drive. Everything appeared to go OK during setup.exe, but in fact the /tmp dir got created with a bad ACL making it unwritable, and as a consequnce I got shell failures during the postinstall scripts and when running the base-files initial setup; you can't create here docs if the /tmp dir is r-o. I haven't yet figured out what exactly went wrong, but one clue is that - now looking at the created dirs on my main box where they appeared on the I: drive - the ACL of the /tmp dir is weird. Here for comparison is the ACL of the /usr dir, seen from the host (remote) side: C:\Documents and Settings\Administratorcacls i:\cygremotewin\usr i:\cygremotewin\usr BUILTIN\Administrators:F UBIK\None:R Everyone:R CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)R Everyone:(OI)(CI)(IO)R Here's how setup.exe created the /tmp dir: C:\Documents and Settings\Administratorcacls i:\cygremotewin\tmp i:\cygremotewin\tmp BUILTIN\Administrators:F UBIK\None:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Everyone:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Account Domain not found(special access:) FILE_READ_DATA CREATOR OWNER:(OI)(CI)(IO)F CREATOR GROUP:(OI)(CI)(IO)(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Everyone:(OI)(CI)(IO)(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA
Re: general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]
On Dec 16 14:24, Dave Korn wrote: I gave it a try and produced an oddity, although possibly just as an artifact of the way I did it: instead of creating a share, I mapped the default admin //sever/I$ share of my main PC as Z: over SMB from inside a VM and installed it to that drive. Everything appeared to go OK during setup.exe, but in fact the /tmp dir got created with a bad ACL making it unwritable, and as a consequnce I got shell failures during the postinstall scripts and when running the base-files initial setup; you can't create here docs if the /tmp dir is r-o. Did the tmp dir get created with the below ACL? If so, it's not R/O. it looks perfectly reasonable for a directory created with 01777 permissions. That's what is done for /tmp in install.cc. C:\Documents and Settings\Administratorcacls i:\cygremotewin\tmp i:\cygremotewin\tmp BUILTIN\Administrators:F Full access for admins. UBIK\None:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Everyone:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Account Domain not found(special access:) FILE_READ_DATA See below. CREATOR OWNER:(OI)(CI)(IO)F Full access for creator-owner for subsequently created objects. CREATOR GROUP:(OI)(CI)(IO)(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Everyone:(OI)(CI)(IO)(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_GENERIC_EXECUTE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES Hmm, what? That thing that says Account Domain not found shows up in the explorer properties dialog security tab as S-1-0-0, or if I run the cacls command from the VM guest side, it is described as NULL SID, which is probably because the VM is XP and the host is 2k and MS only made cacls.exe smart enough to recognize the null sid in the XP version, but that doesn't explain what it's doing there in the first place! Does this symptom suggest any possibilities to anyone? Unfortunately not. It's really officially the NULL SID. The NULL SID ACE is created when at least one of the special SUID, SGID or VTX bits are set in the permissions. FILE_READ_DATA in the NULL SID is the marker for the VTX bit. As
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Dec 16 11:16, Christopher Faylor wrote: On Wed, Dec 16, 2009 at 09:56:11AM +0100, Corinna Vinschen wrote: Changes by:c...@ouch 2009-12-13 19:23:43 Ouch. Ouch. There's actually no package_message.h file in the repository. Could you please check it in? I've checked it in. Thanks. Btw., is setup finished for the 1.7.1 release with this patch or is there more to come? There is more to come. I have found a problem with the latest setup.exe when running on Windows 9x that I still need to fix. And, I have the On 9x?!? I applied a patch a couple of days ago so that the new setup won't run on 9x anymore. It just shows a message box. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Wed, Dec 16, 2009 at 05:37:27PM +0100, Corinna Vinschen wrote: On Dec 16 11:16, Christopher Faylor wrote: On Wed, Dec 16, 2009 at 09:56:11AM +0100, Corinna Vinschen wrote: Changes by: c...@ouch 2009-12-13 19:23:43 Ouch. Ouch. There's actually no package_message.h file in the repository. Could you please check it in? I've checked it in. Thanks. Btw., is setup finished for the 1.7.1 release with this patch or is there more to come? There is more to come. I have found a problem with the latest setup.exe when running on Windows 9x that I still need to fix. And, I have the On 9x?!? I applied a patch a couple of days ago so that the new setup won't run on 9x anymore. It just shows a message box. Yes, I saw that. It was rather puzzling given our private email discussion where I advocated for making the trunk setup NT-only and you indicated that it was supposed to work. Part of my pending changes resurrect 9x support so that we can use one binary for legacy and regular cygwin installations. cgf
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Dec 16 12:09, Christopher Faylor wrote: On Wed, Dec 16, 2009 at 05:37:27PM +0100, Corinna Vinschen wrote: On Dec 16 11:16, Christopher Faylor wrote: On Wed, Dec 16, 2009 at 09:56:11AM +0100, Corinna Vinschen wrote: Changes by: c...@ouch 2009-12-13 19:23:43 Ouch. Ouch. There's actually no package_message.h file in the repository. Could you please check it in? I've checked it in. Thanks. Btw., is setup finished for the 1.7.1 release with this patch or is there more to come? There is more to come. I have found a problem with the latest setup.exe when running on Windows 9x that I still need to fix. And, I have the On 9x?!? I applied a patch a couple of days ago so that the new setup won't run on 9x anymore. It just shows a message box. Yes, I saw that. It was rather puzzling given our private email discussion where I advocated for making the trunk setup NT-only and you indicated that it was supposed to work. Part of my pending changes resurrect 9x support so that we can use one binary for legacy and regular cygwin installations. But we discussed this on the developers list. The old setup will be setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather puzzled that you want to change this again. I have matching local changes to the web page waiting. Please don't change this again. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
2009/12/16 Corinna Vinschen: But we discussed this on the developers list. The old setup will be setup-legacy.exe and setup.exe is only for 1.7 and later. Does setup.exe have the warning about upgrading from 1.5 to 1.7 that Dave had suggested? Andy
Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...
On Wed, Dec 16, 2009 at 06:18:38PM +0100, Corinna Vinschen wrote: But we discussed this on the developers list. The old setup will be setup-legacy.exe and setup.exe is only for 1.7 and later. I'm rather puzzled that you want to change this again. I have matching local changes to the web page waiting. Please don't change this again. Since I have to change source code to understand the release-legacy directory, I opted to just do it in the trunk rather than the ancient setup 1.5 branch. There will still be a setup-legacy binary. cgf
Re: general setup.exe status incl network install [was Re: setup ChangeLog IniDBBuilder.h IniDBBuilderPac ...]
Corinna Vinschen wrote: On Dec 16 14:24, Dave Korn wrote: Does this symptom suggest any possibilities to anyone? Unfortunately not. It's really officially the NULL SID. The NULL SID ACE is created when at least one of the special SUID, SGID or VTX bits are set in the permissions. Ah, ok. Well, I've got more. Here's what happens when you launch the first cygwin shell after completing the install: Copying skeleton files. These files are for the user to personalise their cygwin experience. They will never be overwritten nor automatically updated. `./.bashrc' - `/home/DaveK//.bashrc' `./.bash_profile' - `/home/DaveK//.bash_profile' `./.inputrc' - `/home/DaveK//.inputrc' bash: cannot create temp file for here document: Device or resource busy I remembered wrong; it's not r-o, it's busy. That error happens again every time you start up a shell, and when you look in the tmp dir, you see that it did in fact manage to create the temp file for the here doc: $ ls -lart /tmp/ total 12 -rw--- 1 Administrators None 122 Dec 16 23:42 sh-thd-1260978391 drwxr-xr-x+ 1 Administrators None0 Dec 17 01:17 .. -rw--- 1 Administrators None 26 Dec 17 01:17 sh-thd-1261018730 -rw--- 1 Administrators None 26 Dec 17 01:18 sh-thd-1261013343 -rw-r--r-- 1 Administrators None0 Dec 17 01:18 foobar -rw-r--r-- 1 Administrators None 866 Dec 17 01:19 bar -rw--- 1 Administrators None 2023 Dec 17 01:20 sh-thd-3715808728 -rw--- 1 Administrators None0 Dec 17 01:20 sh-thd-1261024743 -rw--- 1 Administrators None 26 Dec 17 01:27 sh-thd-1261038942 -rw--- 1 Administrators None0 Dec 17 01:28 sh-thd-1261038922 drwxrwxrwt+ 1 Administrators None0 Dec 17 01:28 . da...@winxp2 ~ $ I think the strace suggests where the problem lies: 350 519655 [main] bash 680 open: 3 = open (/tmp/sh-thd-1261038922, 0x10E01) [ ... snip ... ] 517 535090 [main] bash 680 open: 4 = open (/tmp/sh-thd-1261038922, 0x1) 454 535544 [main] bash 680 close: close (3) 476 536020 [main] bash 680 fhandler_base::close: closing '/tmp/sh-thd-1261038922' handle 0x6A4 679 536699 [main] bash 680 close: 0 = close (3) 563 537262 [main] bash 680 normalize_posix_path: src /tmp/sh-thd-1261038922 605 537867 [main] bash 680 normalize_posix_path: /tmp/sh-thd-1261038922 = normalize_posix_path (/tmp/sh-thd-1261038922) 449 538316 [main] bash 680 mount_info::conv_to_win32_path: conv_to_win32_path (/tmp/sh-thd-1261038922) 571 538887 [main] bash 680 set_flags: flags: binary (0x2) 806 539693 [main] bash 680 mount_info::conv_to_win32_path: src_path /tmp/sh-thd-1261038922, dst Z:\cygremotewin2\tmp\sh-thd-1261038922, flags 0x3000A, rc 0 1641 541334 [main] bash 680 symlink_info::check: not a symlink 1003 542337 [main] bash 680 symlink_info::check: 0 = symlink.check (Z:\cygremotewin2\tmp\sh-thd-1261038922, 0x22B5E8) (0x3000A) 466 542803 [main] bash 680 path_conv::check: this-path(Z:\cygremotewin2\tmp\sh-thd-1261038922), has_acls(1) 547 543350 [main] bash 680 seterrno_from_win_error: /ext/build/netrel/src/cygwin-1.7.0-62/winsup/cygwin/syscalls.cc:674 windows error 32 496 543846 [main] bash 680 geterrno_from_win_error: windows error 32 == errno 16 449 544295 [main] bash 680 __set_errno: void seterrno_from_win_error(const char*, int, DWORD):319 val 16 433 544728 [main] bash 680 unlink: -1 = unlink (/tmp/sh-thd-1261038922) 740 545468 [main] bash 680 close: close (4) 498 545966 [main] bash 680 fhandler_base::close: closing '/tmp/sh-thd-1261038922' handle 0x6A0 1121 547087 [main] bash 680 close: 0 = close (4) It looks like the unlink-while-you-still-have-an-open-handle-to-the-file trick isn't working on SMB mounts, perhaps? cheers, DaveK
