Re: cygpath -u inside backticks differs
Eric - thanks for the info! I see the problem, yes, and it is simple - I have completely slepth through the $() business :-) I am all set now - thanks! Ivan -- 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
cygpath -u inside backticks differs
It may be something very simple, but I just cannot figure what it is, nor can I find anything on the forums. Here - see the different results: / echo `cygpath.exe -u '\\DAEMON1\anrdaemon\.profile'` /c/DAEMON1/anrdaemon/.profile / cygpath.exe -u '\\DAEMON1\anrdaemon\.profile' //DAEMON1/anrdaemon/.profile So cygpath in backticks slaps a drive at the front, while otherwise it does ... well, what I expect. Does anyone know why? Or know a thread where this is explained? Many thanks! Ivan PS: I am running a fairly recent version of cygwin 1.7.27 ... and I just checked it in 1.7.29 -- 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: AGAIN - cp: skipping file ... as it was replaced while being copied
OK - just for the record and in case this ever needs to be debugged, here's the result. I got the latest snapshot cygwin1-20080327.dll.bz2. It fixed the cp from network problem, but created a strange issue with mounted disks. Here it is. Normally I have mounted c: and d: like this mount c:/ /c; ls /c mount d:/ /d; ls /d so that /c and /d lead to the top-levels of c: and d: respectively. As a result, I _normally_ have this: /tmp mount C:\bin\cygwin\bin on /usr/bin type system (binmode) C:\bin\cygwin\lib on /usr/lib type system (binmode) C:\bin\cygwin on / type system (binmode) c: on /c type system (binmode) d: on /d type system (binmode) Now, with the dev snapshot cygwin1.dll, all is well except that ls /d seems to list /c and in fact ls /any_single_letter seems to behave like ls /c! I can still see d: under ls /cygdrive/d/, but not under its mount point, which is /d/. Also, when I list /c I get an error regarding not being able to open Documents\ and\ Settings. Strange! So I reverted back to the original cygwin1.dll :-) If there is any interest on the part of any cygwin developer in pursuing this matter, I'd be happy to cooperate, but other than that I'll leave it at that - at least for the near future. On Apr 3 20:35, Ivan Dobrianov wrote: Hi and sorry for the clutter, but I can't figure it out! I have this familiar situation when trying to copy from the network: cp //walnetapp01/SRD/LegacyBugs/148000-148999/148708/some_file.txt ./ cp: skipping file `//walnetapp01/SRD/LegacyBugs/148000-148999/148708/some_file.txt', as it was replaced while being copied Now, I looked through the mailing list archives and found two relevant threads on this subject, namely: ml/cygwin/2006-01/msg00804.html ml/cygwin/2006-11/msg00525.html The thing is that neither of them ends up with a prescription of how to fix the problem :-) In message 2006-11/msg00604.html, Corinna says: I'm going to add a special case for this file system. Please give the next developer's snapshot from http://www.cygwin.com/snapshots/ a try. Well, here I am in April 2008, with a fresh new Cygwin installation - I am assuming that by now this prblem whould have been resolved in the main branch. Am I wrong? Do I have to do anything special? The patch is in CVS, not in the latest release. You could try the latest developer snapshot from http://cygwin.com/snapshots/, but for the time being, there's no fix for the release itself. Note that snapshots are not made for production environments. Use at your own risk. Corinna -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
AGAIN - cp: skipping file ... as it was replaced while being copied
Hi and sorry for the clutter, but I can't figure it out! I have this familiar situation when trying to copy from the network: cp //walnetapp01/SRD/LegacyBugs/148000-148999/148708/some_file.txt ./ cp: skipping file `//walnetapp01/SRD/LegacyBugs/148000-148999/148708/some_file.txt', as it was replaced while being copied Now, I looked through the mailing list archives and found two relevant threads on this subject, namely: ml/cygwin/2006-01/msg00804.html ml/cygwin/2006-11/msg00525.html The thing is that neither of them ends up with a prescription of how to fix the problem :-) In message 2006-11/msg00604.html, Corinna says: I'm going to add a special case for this file system. Please give the next developer's snapshot from http://www.cygwin.com/snapshots/ a try. Well, here I am in April 2008, with a fresh new Cygwin installation - I am assuming that by now this prblem whould have been resolved in the main branch. Am I wrong? Do I have to do anything special? Here is the output of the proverbial ./getvolinfo.exe //walnetapp01/SRD: rootdir: \\walnetapp01\SRD\ Volume Name: SRD Serial Number : 771869145 Max Filenamelength : 255 Filesystemname : NTFS Flags: 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 And yes, calling ls -i twice on the network file gives me different i-node numbers. All this seems to have been discussed more than a year ago. Is there no solution for that yet? I'll appreciate any info! PS: Here is my version info [from cygcheck -s]: 1829k 2008/03/05 C:\bin\cygwin\bin\cygwin1.dll Cygwin DLL version info: DLL version: 1.5.25 DLL epoch: 19 DLL bad signal mask: 19005 DLL old termios: 5 DLL malloc env: 28 API major: 0 API minor: 156 Shared data: 4 DLL identifier: cygwin1 Mount registry: 2 Cygnus registry name: Cygnus Solutions Cygwin registry name: Cygwin Program options name: Program Options Cygwin mount registry name: mounts v2 Cygdrive flags: cygdrive flags Cygdrive prefix: cygdrive prefix Cygdrive default prefix: Build date: Wed Mar 5 19:27:59 CET 2008 CVS tag: cr-0x5f1 Shared id: cygwin1S4 It's the latest available right now - /c/download/cygwin/1.5.25-11/ ! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
All Windows-created files seem to have mode -rwxrwxrwx
Sorry is this has been asked 1000 times, but even though there are many references to permissions setting in the FAQ and User guide, nohting explains the following. THE FACTS: I have Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 and Cygwin cygwin_1.3.14-1 gotten and installed yesterday, with settings CYGWIN = `ntea' and the disks are NTFS, e.g.: e: hd NTFS 70001Mb 13% CP CS UN PA FC DATA THE PROBLEM: All is well except that all Windows-created files seem to have permissions -rwxrwxrwx. Including text files created by say Notepad. All are executable. I have no problem with reading or chaning permissions from inside Cygwin. Also files created from Cygwin have reasonable permissions: -rw-rw-rw-. It is just file created from Windows applications that are always executable. Any clues? Thanks! PS: I do not want to bother with 'ntsec' - security is not an issue at the moment. PS2: I have used previous versions of cygwin on a number of NTFS-disked machins and never seen this. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: All Windows-created files seem to have mode -rwxrwxrwx
For whatever this is worth: Setting CYGWIN to ntea nontsec seems to bring things to normal. I guess it's not my destiny to ever understand the intricacies of ntsec :-) = * From: lhall at pop dot ma dot ultranet dot com lhall at pop dot ma dot ultranet dot com * To: cke at highlandshighspeed dot net, cygwin at cygwin dot com * Date: Thu, 31 Oct 2002 12:57:40 -0500 * Subject: Re: All Windows-created files seem to have mode -rwxrwxrwx * Reply-to: lhall at rfk dot com 'ntsec' is on by default since since Cygwin package 1.3.13. Larry Original Message: - From: Chris K Ellsworth [EMAIL PROTECTED] Date: Thu, 31 Oct 2002 09:44:05 -0800 To: [EMAIL PROTECTED] Subject: Re: All Windows-created files seem to have mode -rwxrwxrwx you probly need ntsec also - Original Message - From: Ivan Dobrianov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 31, 2002 9:34 AM Subject: All Windows-created files seem to have mode -rwxrwxrwx Sorry is this has been asked 1000 times, but even though there are many references to permissions setting in the FAQ and User guide, nohting explains the following. THE FACTS: I have Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 and Cygwin cygwin_1.3.14-1 gotten and installed yesterday, with settings CYGWIN = `ntea' and the disks are NTFS, e.g.: e: hd NTFS 70001Mb 13% CP CS UN PA FC DATA THE PROBLEM: All is well except that all Windows-created files seem to have permissions -rwxrwxrwx. Including text files created by say Notepad. All are executable. I have no problem with reading or chaning permissions from inside Cygwin. Also files created from Cygwin have reasonable permissions: -rw-rw-rw-. It is just file created from Windows applications that are always executable. Any clues? Thanks! PS: I do not want to bother with 'ntsec' - security is not an issue at the moment. PS2: I have used previous versions of cygwin on a number of NTFS-disked machins and never seen this. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: tar won't restore permissions
Ok, I posted this question more than a year ago ... and the problem is still present in the latest Cygwin builds: tar xpvf myArchive.tar will not restore read-only permissions, i.e. files with r-- perms will get rw- permission when restored!!! I am seeing this on Win NT, 2000, and XP on FAT32 and NTFS with and without setting $CYGWIN to ntea or ntfs. This used to work right in the days of B20. I. To see the bug: 1) copy the follwing text to a file called demo - echo [ -d tar_bug ] || mkdir tar_bug cd tar_bug rm -rf * cat myFileEOF qwerty EOF chmod 444 myFile ls -l myFile tar cvf myArchive.tar myFile tar tvf myArchive.tar sleep 2 mkdir untarred cd untarred tar xpvf ../myArchive.tar -U ls -l 2) Do: sh demo 3) I get the follwing output: -r--r--r-- 1 administ None8 Jan 20 11:55 myFile myFile -r--r--r-- administrator/None 8 2001-01-20 11:55:14 myFile myFile total 0 -rw-r--r-- 1 administ None8 Jan 20 11:55 myFile *** Note that myFile is writable in the end! *** NOTE: Yes, if you CYGWIN=ntea under NTFS, the problem _SEEMS_ to get fixed, but upon inspection, with say Explorer, it turns out the file is still writable - the problem is just being masked! II. The fix. Well, I have a tweaked version of tar-1.13.19-1 which seems to work fine. Here is the hacky patch of extract.c that does the trick ~/tar_fix diff extract.c_DUP_00 extract.c 125a126,127 /* printf (File: %s\n, file_name); */ 135c137,139 if (permstatus == ARCHIVED_PERMSTATUS --- /* Ivan says: for whatever reason the caller THINKS the mode is ok, but it is not, at least under Win NT w/ cygwin */ if (0 permstatus == ARCHIVED_PERMSTATUS 158a163,164 /* printf (File: %s - mode: %o\n, file_name, mode); */ ~/tar_fix I don't know if this is the right way to fix the problem - probably it is not! I'll leave it to more knowledgeable people to do the real thing ... or point the workaround that has been eluding me for that past year and more :-) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
