Re: SSH - Can't Login (3rd Post)
On Sat, Aug 28, 2010 at 4:34 PM, Auteria W. Winzer Jr. wrote: > I've posted this 3 times now. I'm wondering if anyone from the Cygwin staff is > receiving it. I've been an outstanding member of the mailing list for a very > long time. Anyway, here's my issue: > > I've set up SSH with no problems in the past, yet when I try to log into > itself > I get the following: > Check the following: ls -la /home//.ssh ls -la /home Does the .ssh folder have permissions 700 and files within 600? Do you have "StrictModes yes" in your sshd_conf file? If so, then the server will ignore the keys in the .ssh sub-directory if the home directory is writeable by anyone other than the Owner. slide -- 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: Windows batch program to open shell at directory specified as argument
On Fri, Aug 27, 2010 at 11:42 AM, Dave Kilroy wrote: > On Thu, Aug 26, 2010 at 11:45 PM, Reckoner wrote: >> I use chere to right-click and open a shell at a given directory, and >> I was wondering if it is possible to setup a windows batch script that >> would accomplish the same thing from the Windows command line. In >> other words something like, >> >> c:> cygwin_start_dir.bat c:\mystuff\directory >> >> which would then open my favourite shell at the c:\mystuff\directory. > > Yes, this is possible. You simply want to grab the command that chere > puts a registry and paste it into a batch file. You probably need to > fix up quoting, and change any %L to %1. > > Run 'chere -r' and look for the text associated with the command key. > > > Cheers, > > Dave. > You could also use something from this site: http://www.mindview.net/Etc/Cygwin/BashHere slide -- 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: build cygwin apps on linux
On Thu, Aug 19, 2010 at 6:23 PM, Christopher Faylor wrote: > On Thu, Aug 19, 2010 at 06:18:11PM -0700, Slide wrote: >>I've looked through the archives and saw some messages about building >>a cross-compiler to build cygwin apps on linux, but most of those >>messages/articles are pretty old. Has anyone done this recently with >>more recent GCC and Cygwin versions? > > Yes. > > cgf > > -- Do you have a list of steps you took or what packages you needed? I'd like to build a cross compiler that I can use on my Linux box that has the same GCC version and same Cygwin packages as the current Cygwin releases. Thanks, slide -- 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
build cygwin apps on linux
I've looked through the archives and saw some messages about building a cross-compiler to build cygwin apps on linux, but most of those messages/articles are pretty old. Has anyone done this recently with more recent GCC and Cygwin versions? Thanks, slide -- 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: Weird directories on Windows share when using rm to delete a directory
On Wed, Jul 7, 2010 at 6:04 AM, Christopher Faylor wrote: > On Wed, Jul 07, 2010 at 05:56:30AM -0700, Slide wrote: >> >> >>> Thanks for your help. ?This problem should be fixed now in CVS. >>> I switched off the entire mechanism which tries to resolve sharing >>> violations for netapp drives. >>> >>> What happens is this: >>> >>> The netapp drive is thoroughly confused when trying to move-and-delete >>> a file or directory using a single handle. ?In case of directories it >>> moves the directories and the subsequent delete call returns success >>> without actually having succeeded. ?In case of files, renaming the file >>> fails with "sharing violation" and the subsequent call for deletion >>> fails with "file has been moved" (I guess you see the confusion here). >>> Above all, when trying to remove a directory tree, after all files in a >>> directory have been removed, opening the directory with only the >>> FILE_SHARE_DELETE sharing flag set fails with a ... sharing violation. >> >>Thanks very much for the awesome and speedy response to this issue. >>This will help keep me sane for a little while longer :-) > > Given Corinna's explanation of the problem, please consider filing a > bug report with NetApp. I know that they'll want to hear about this. > I'll work with our IT staff. Thanks! -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Weird directories on Windows share when using rm to delete a directory
> Thanks for your help. This problem should be fixed now in CVS. > I switched off the entire mechanism which tries to resolve sharing > violations for netapp drives. > > What happens is this: > > The netapp drive is thoroughly confused when trying to move-and-delete > a file or directory using a single handle. In case of directories it > moves the directories and the subsequent delete call returns success > without actually having succeeded. In case of files, renaming the file > fails with "sharing violation" and the subsequent call for deletion > fails with "file has been moved" (I guess you see the confusion here). > Above all, when trying to remove a directory tree, after all files in a > directory have been removed, opening the directory with only the > FILE_SHARE_DELETE sharing flag set fails with a ... sharing violation. > > > Corinna > Corinna, Thanks very much for the awesome and speedy response to this issue. This will help keep me sane for a little while longer :-) Thanks, slide -- 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: Weird directories on Windows share when using rm to delete a directory
On Tue, Jul 6, 2010 at 1:02 AM, Corinna Vinschen wrote: > On Jul 5 23:00, Slide wrote: >> >> >> > This funtionality wasn't available in 1.5, so, yes, this would only >> > have started with 1.7. >> > >> > So it seems that these netapp drives somehow don't understand the >> > entirely normal FileDispositionInformation method, or they ignore it for >> > some unknown reason. >> > >> > Unfortunately the strace from your OP isn't helpful since it >> > only contains the deletion of a single file. What would help is >> > an strace of a rmdir or rm -rf(*) of a directory which then creates >> > one of those temporary directories. There are lots of potential >> > debug messages wqhich might sched a light here. >> > >> > >> > Corinna >> > >> > (*) If possible with not more than a single file in the dir, so that >> > the strace doesn't become too big. >> > >> >> The directory structure is like the following: >> >> //share/directory/path/to/dir/hammer.ba_ >> >> Command is "rm -rf //share/directory/path/to/dir" > > Thanks. The strace doesn't help, though. The rmdir of foo works > without any problem, so not even a single debug output is generated. > > I have an idea or two what could be the problem of the netapp drive, > but that requires testing with a Cygwin DLL with enhanced debug output > in the unlink/rmdir functionality. > > Would you mind to play guinea pig if I send you the link to such a > DLL via PM? > > I'd love to play guinea pig if it will help get the issue resolved :-) Thanks, slide -- 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: Weird directories on Windows share when using rm to delete a directory
> This funtionality wasn't available in 1.5, so, yes, this would only > have started with 1.7. > > So it seems that these netapp drives somehow don't understand the > entirely normal FileDispositionInformation method, or they ignore it for > some unknown reason. > > Unfortunately the strace from your OP isn't helpful since it > only contains the deletion of a single file. What would help is > an strace of a rmdir or rm -rf(*) of a directory which then creates > one of those temporary directories. There are lots of potential > debug messages wqhich might sched a light here. > > > Corinna > > (*) If possible with not more than a single file in the dir, so that > the strace doesn't become too big. > The directory structure is like the following: //share/directory/path/to/dir/hammer.ba_ Command is "rm -rf //share/directory/path/to/dir" 1 1 [main] rm 9536 open_shared: name shared.5, n 5, shared 0x60FC (wanted 0x60FC), h 0xD4 181 182 [main] rm 9536 heap_init: heap base 0xC7, heap top 0xC7 86 268 [main] rm 9536 open_shared: name S-1-5-21-1801674531-527237240-682003330-50333.1, n 1, shared 0x60FD (wanted 0x60FD), h 0xD8 61 329 [main] rm 9536 user_info::create: opening user shared for 'S-1-5-21-1801674531-527237240-682003330-50333' at 0x60FD 60 389 [main] rm 9536 user_info::create: user shared version 6112AFB3 79 468 [main] rm 9536 events_init: windows_system_directory 'C:\Windows\system32\', windows_system_directory_length 20 72 540 [main] rm 9536 dll_crt0_0: finished dll_crt0_0 initialization 152 692 [main] rm 9536 _cygtls::remove: wait 0x 59 751 [main] rm 9536 _cygtls::remove: removed 0x28CE64 element 0 96 847 [main] rm 9536 _cygtls::remove: wait 0x 50 897 [main] rm 9536 _cygtls::remove: removed 0x28CE64 element 0 81 978 [main] rm 9536 _cygtls::remove: wait 0x 491027 [main] rm 9536 _cygtls::remove: removed 0x28CE64 element 0 2891316 [main] rm 9536 _cygwin_istext_for_stdio: fd 0: not open 491365 [main] rm 9536 _cygwin_istext_for_stdio: fd 1: not open 471412 [main] rm 9536 _cygwin_istext_for_stdio: fd 2: not open 5051917 [main] rm 9536 mount_info::conv_to_posix_path: conv_to_posix_path (C:\Users\REPLACED\ccviews\REPLACED_TTC1_DB06-30-2010\vobs\ttc_focus\multicore\chimera\ecos, no-keep-rel, no-add-slash) 972014 [main] rm 9536 normalize_win32_path: C:\Users\REPLACED\ccviews\REPLACED_TTC1_DB06-30-2010\vobs\ttc_focus\multicore\chimera\ecos = normalize_win32_path (C:\Users\REPLACED\ccviews\REPLACED_TTC1_DB06-30-2010\vobs\ttc_focus\multicore\chimera\ecos) 562070 [main] rm 9536 mount_info::conv_to_posix_path: /cygdrive/c/Users/REPLACED/ccviews/REPLACED_TTC1_DB06-30-2010/vobs/ttc_focus/multicore/chimera/ecos = conv_to_posix_path (C:\Users\REPLACED\ccviews\REPLACED_TTC1_DB06-30-2010\vobs\ttc_focus\multicore\chimera\ecos) 1212191 [main] rm (9536) open_shared: name cygpid.9536, n 9536, shared 0x60FF (wanted 0x60FF), h 0x110 2032394 [main] rm 9536 ** 492443 [main] rm 9536 Program name: C:\cygwin\bin\rm.exe (pid 9536, ppid 1) 582501 [main] rm 9536 App version: 1007.5, api: 0.225 472548 [main] rm 9536 DLL version: 1007.5, api: 0.225 472595 [main] rm 9536 DLL build:2010-04-12 19:07 502645 [main] rm 9536 OS version: Windows NT-6.1 462691 [main] rm 9536 Heap size:402653184 472738 [main] rm 9536 ** 472785 [main] rm 9536 pinfo::thisproc: myself->dwProcessId 9536 482833 [main] rm 9536 time: 1278395683 = time (0) 69499782 [main] rm 9536 parse_options: glob (called func) 1069888 [main] rm 9536 parse_options: dosfilewarning 0 929980 [main] rm 9536 parse_options: returning 107 10087 [main] rm 9536 environ_init: GetEnvironmentStrings returned 0x46AE60 93 10180 [main] rm 9536 environ_init: 0xC982B0: !C:=C:\cygwin\bin 93 10273 [main] rm 9536 environ_init: 0xC982C8: ALLUSERSPROFILE=C:\ProgramData 92 10365 [main] rm 9536 environ_init: 0xC982F0: APPDATA=C:\Users\REPLACED\AppData\Roaming 92 10457 [main] rm 9536 environ_init: 0xC98320: COMMONPROGRAMFILES=C:\Program Files (x86)\Common Files 92 10549 [main] rm 9536 environ_init: 0xC98360: COMPUTERNAME=REPLACED-DEV 93 10642 [main] rm 9536 environ_init: 0xC98380: COMSPEC=C:\Windows\system32\cmd.exe 93 10735 [main] rm 9536 environ_init: 0xC983B0: CVS_RSH=/bin/ssh 92 10827 [main] rm 9536 environ_init: 0xC983C8: CYGWIN=noglob nodosfilewarning 94 10921 [main] rm 9536 environ_init: 0xC983F0: CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files 93 11014 [main] rm 9536 environ_init: 0xC98438: CommonProgramW6432=C:\Program Files\Common Files 91 11105 [main] rm 9536 environ_init: 0xC98470: FP_NO_HOST_CHECK=NO 116 11221 [main] rm 9536 getwinenv: can't
Re: Weird directories on Windows share when using rm to delete a directory
> > So, IIUC, youre'saying that the directories get renamed to this > temporary name, but they never disappear after rm -rf? Are you > sure that no other process is accessing them? > > Does Cygwin recognize the drive as netapp if you add a mount point for > it? How to check: If the drive has been mounted with a drive letter, > say X:, what does `mount' print as drive type of /cygdrive/x? Or, if > the drive is used via UNC path, just mount it temporarily like this: > > $ mount -f //server/share /mnt > > And see what a `mount' command prints for the .mnt mount point: > > $ mount > > > Corinna > I'm pretty sure there are no other processes accessing the files. $ mount ... Y: on /cygdrive/y type netapp (binary,posix=0,user,noumount,auto) So, yes, it does see it as a netapp. Now, from my horrible memory, it _seems_ like this started happening when we upgraded to Cygwin 1.7 from Cygwin 1.5. I don't know that for sure though, it just _seems_ that that is what happened. Thanks, slide -- 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: Weird directories on Windows share when using rm to delete a directory
On Thu, Jul 1, 2010 at 3:26 PM, Larry Hall (Cygwin) wrote: > On 7/1/2010 5:52 PM, Slide wrote: > > > >> What sort of information would you need for the share? I believe it is >> actually a Linux box running Samba for the share. I would have to >> double check with my IT department on that. I should be able to get >> any information needed about the share to help workaround the issue. > > Knowing the source system O/S, version, sharing protocol and version, > and file system type would be helpful. Also, please provide the output > of /usr/lib/csih/getVolInfo for the mounted path. > The system is a NetApp. This is the information that my IT guy gave me. 1) System O/S and Version - ONTAP 7.2.6.1P8 2) Sharing protocol and version - CIFS 3) File system type - WAFL (not really a file system according to wikipedia) And here is the info from getVolInfo Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 50512157 Max Filenamelength : 255 Filesystemname : Flags : 4000f FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: TRUE FILE_PERSISTENT_ACLS: TRUE 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 : TRUE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE -- 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: Weird directories on Windows share when using rm to delete a directory
On Thu, Jul 1, 2010 at 2:28 PM, Eric Blake wrote: > On 07/01/2010 03:24 PM, Slide wrote: >> I am seeing a VERY odd problem. If I run "/usr/bin/rm -rf >> //computer/share/path/to/dir" to remove a directory on a network >> share. I get some directories created with names like >> .XXXf8a0015e3b00c65f07a9f20c7a31 at the ROOT of the share (where >> XXX is unprintable character with the value 0x3f). I ran the command >> with strace, but didn't see anything in there that would point to why >> the directory is created. >> >> If I run the corresponding Windows command "rmdir /s /q >> \\computer\share\path\to\dir" I do NOT see the same thing occur, so >> something in Cygwin is causing this issue. I am running Cygwin 1.7 >> updated today. > > This is due to cygwin emulating the ability to delete a file that is > still open. Since windows doesn't directly allow it, cygwin instead > renames it out of the way, and relies on windows delete-on-close > semantics to get rid of that temporary name after everything finally > lets go of the file. But if the delete-on-close stuff isn't working for > your particular network share, we'd need a few more details about your > share to allow us to work around the issue (probably by refusing to > attempt deleting an open file, if your share doesn't have any better > semantics available). > What sort of information would you need for the share? I believe it is actually a Linux box running Samba for the share. I would have to double check with my IT department on that. I should be able to get any information needed about the share to help workaround the issue. Thanks! slide -- slide-o-blog http://slide-o-blog.blogspot.com/ -- 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
Weird directories on Windows share when using rm to delete a directory
atestBuild/ttc = normalize_posix_path (//azsappauto/pca/Automation/ReleaseBinFiles/LatestBuild/ttc) 3163 625200 [main] rm 8612 mount_info::conv_to_win32_path: conv_to_win32_path(//azsappauto/pca/Automation/ReleaseBinFiles/LatestBuild/ttc) 2110 627310 [main] rm 8612 set_flags: flags: binary (0x2) 1148 628458 [main] rm 8612 mount_info::conv_to_win32_path: src_path //azsappauto/pca/Automation/ReleaseBinFiles/LatestBuild/ttc, dst \\azsappauto\pca\Automation\ReleaseBinFiles\LatestBuild\ttc, flags 0x4022, rc 0 3572 632030 [main] rm 8612 symlink_info::check: 0x0 = NtCreateFile (\??\UNC\azsappauto\pca\Automation\ReleaseBinFiles\LatestBuild\ttc) 2518 634548 [main] rm 8612 symlink_info::check: not a symlink 1422 635970 [main] rm 8612 symlink_info::check: 0 = symlink.check (\\azsappauto\pca\Automation\ReleaseBinFiles\LatestBuild\ttc, 0x22B640) (0x4022) 2018 637988 [main] rm 8612 path_conv::check: this->path(\\azsappauto\pca\Automation\ReleaseBinFiles\LatestBuild\ttc), has_acls(1) 2212 640200 [main] rm 8612 build_fh_pc: fh 0x6122647C 3163 643363 [main] rm 8612 rmdir: 0 = rmdir (//azsappauto/pca/Automation/ReleaseBinFiles/LatestBuild/ttc) 2385 645748 [main] rm 8612 close: close (4) 1031 646779 [main] rm 8612 fhandler_base::close: closing '//azsappauto/pca/Automation/ReleaseBinFiles/LatestBuild/ttc' handle 0x234 2481 649260 [main] rm 8612 close: 0 = close (4) 1843 651103 [main] rm 8612 close: close (0) 1184 652287 [main] rm 8612 init_cygheap::manage_console_count: fhandler_console::close: console_count 2, amount -1, ctty /dev/console, avoid_freeing_console 0 3401 655688 [main] rm 8612 close: 0 = close (0) 1768 657456 [main] rm 8612 close: close (1) 1162 658618 [main] rm 8612 init_cygheap::manage_console_count: fhandler_console::close: console_count 1, amount -1, ctty /dev/console, avoid_freeing_console 0 2934 661552 [main] rm 8612 close: 0 = close (1) 1906 663458 [main] rm 8612 close: close (2) 1166 664624 [main] rm 8612 init_cygheap::manage_console_count: fhandler_console::close: console_count 0, amount -1, ctty /dev/console, avoid_freeing_console 0 2940 667564 [main] rm 8612 close: 0 = close (2) 1836 669400 [main] rm 8612 do_exit: do_exit (0), exit_state 1 1190 670590 [main] rm 8612 void: 0x0 = signal (20, 0x1) 1157 671747 [main] rm 8612 void: 0x0 = signal (1, 0x1) 1079 672826 [main] rm 8612 void: 0x0 = signal (2, 0x1) 1098 673924 [main] rm 8612 void: 0x0 = signal (3, 0x1) 1286 675210 [main] rm 8612 sigproc_terminate: entering 1108 676318 [main] rm 8612 sig_send: sendsig 0x2D8, pid 8612, signal -42, its_me 1 2047 678365 [sig] rm 8612 wait_sig: saw __SIGEXIT -24 678341 [main] rm 8612 sig_send: Not waiting for sigcomplete. its_me 1 signal -42 3252 681593 [main] rm 8612 sig_send: returning 0x0 from sending signal -42 18 681611 [sig] rm 8612 wait_sig: signal thread exiting 2288 683899 [main] rm 8612 proc_terminate: nprocs 0 1228 685127 [main] rm 8612 proc_terminate: leaving 1726 686853 [main] rm 8612 __to_clock_t: dwHighDateTime 0, dwLowDateTime 468750 2063 688916 [main] rm 8612 __to_clock_t: total 0000 002E 1158 690074 [main] rm 8612 __to_clock_t: dwHighDateTime 0, dwLowDateTime 156250 2098 692172 [main] rm 8612 __to_clock_t: total 000F 1812 693984 [main] rm 8612 pinfo::exit: Calling ExitProcess n 0x0, exitcode 0x0 Thanks, slide -- slide-o-blog http://slide-o-blog.blogspot.com/ -- 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
