Re: cp: skipping file 'file', as it was replaced while being copied

[Kenneth Wolcott]

On Mon, May 16, 2016 at 2:49 PM, Linda Walsh  wrote:
> Kenneth Wolcott wrote:
>>
>> Hi;
>>
>>   cp: skipping file 'file', as it was replaced while being copied
>>
>>   I have several mounted partitions on my Windows machine (64bit Windows
>> 7).
>>
>>   Copying a file using cygwin cp , via mintty, from a mounted drive to
>> a local path, I frequently get the aforementioned message.
>>
>>   Is the partition not properly understood by Cygwin?
>>
>>   I really dislike having to use Windows in the first place, at least
>> Cygwin, when it works, makes it more bearable.
>>
>> The actual command was (line broken by backslash by me to make it more
>> readable):
>>
>>  cp /cygdrive/p/Engineering/Ken_Wolcott/new_Mobility_Audit_script/try1.pl
>> \
>> /cygdrive/c/Documents\ and\ Settings/kwolcott/Desktop/files4trombone/.
>>
> ---
> Does your 'cp' have any aliases or functions that get run?
>
> For example if you have a "cp -a" or "cp -au" as an alias, this
> can cause icky problems copying to or from a samba network drive
> from or to a local drive.
>
> I don't know if it is fixed in the latest tree, but I have
> a feeling it is not, because it's dang hard to fix.  But it has to
> do with maintaining files that are *linked* where it updates one of
> the linked files, then tries to copy the other, and finds it gone or
> finds some different answer for the link's updating due to it already
> having been copied over via the earlier linked-file.
>
> This can also happen due to having 2 differently-cased versions of the
> same file (as windows sees them as 1 file and tries to get rid of the copy).
> It can be reproduced on linux with any fs that allows
> case-insensitivity (but may also be case preserving).  Besides xfs
> having that for ascii since before xfs was on linux, I think some other
> FS's, zfs, maybe, and some planned future extensions
> to existing file systems.   Again, don't know the status of this
> bug either, but it might be related to how the case-insensitivity is
> done in the file system implementing it.
>
> Why do you have 'documents and settings' on your PC?  That went away
> with XP and was replaced by 'Users'.  Is the local file system
> NTFS?

1. I do think that the problem could be caused by have mixed-case
files in a case-insensitive partition..

2. I most often use the full path for cp, mv, rm, etc to avoid
customized behavior, so I don't think that's it.

3. I see that the "Documents and Settings" is a symlink, so I removed
it; thanks for mentioning that.

Thanks,
Ken

--
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: [ATN: git maintainer] Git package depends on python

[Yaakov Selkowitz]

On 2016-05-16 18:24, Warren Young wrote:

On May 16, 2016, at 5:15 PM, Jon Ross  wrote:


Nor can I find any python files in the git package.


/usr/libexec/git-core/git-p4

I expect it is that file (or another like it) that cygport is finding and
automatically adding the python dependency.


Exactly.


In the past, packages have had to be restructured to extract such non-core
commands to avoid this.  In this case, it could be a git-p4 package, just
for those rare people who use both Git and Perforce.


+1 (and obviously it's manpage should go there too).

--
Yaakov

--
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: [ATN: git maintainer] Git package depends on python

[Warren Young]

On May 16, 2016, at 5:15 PM, Jon Ross  wrote:
> 
> Nor can I find any python files in the git package.

/usr/libexec/git-core/git-p4

I expect it is that file (or another like it) that cygport is finding and 
automatically adding the python dependency.

In the past, packages have had to be restructured to extract such non-core 
commands to avoid this.  In this case, it could be a git-p4 package, just for 
those rare people who use both Git and Perforce.
--
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

[ATN: git maintainer] Git package depends on python

[Jon Ross]

It looks like the git package installs python as a dependency. It
causes problems if you need a different win python runtime for your
projects.


Also, git doesn't seem to use python. I un-install python via setup
and git continues to work fine (at least for my typical usage). Nor
can I find any python files in the git package.


Seems a heavyweight dependency, and it doesn't seem to be used. Why is it there?


$ cygcheck.exe -fv /usr/bin/git
/usr/bin/git: found in package git-2.8.0-1


$ uname -a
CYGWIN_NT-6.1 2.5.1(0.297/5/3) 2016-04-21 22:14 x86_64 Cygwin

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: cp: skipping file 'file', as it was replaced while being copied

[Linda Walsh]

Kenneth Wolcott wrote:

Hi;

  cp: skipping file 'file', as it was replaced while being copied

  I have several mounted partitions on my Windows machine (64bit Windows 7).

  Copying a file using cygwin cp , via mintty, from a mounted drive to
a local path, I frequently get the aforementioned message.

  Is the partition not properly understood by Cygwin?

  I really dislike having to use Windows in the first place, at least
Cygwin, when it works, makes it more bearable.

The actual command was (line broken by backslash by me to make it more
readable):

 cp /cygdrive/p/Engineering/Ken_Wolcott/new_Mobility_Audit_script/try1.pl \
/cygdrive/c/Documents\ and\ Settings/kwolcott/Desktop/files4trombone/.


---
Does your 'cp' have any aliases or functions that get run?

For example if you have a "cp -a" or "cp -au" as an alias, this
can cause icky problems copying to or from a samba network drive
from or to a local drive.

I don't know if it is fixed in the latest tree, but I have
a feeling it is not, because it's dang hard to fix.  But it has to
do with maintaining files that are *linked* where it updates one of
the linked files, then tries to copy the other, and finds it gone or
finds some different answer for the link's updating due to it already
having been copied over via the earlier linked-file.

This can also happen due to having 2 differently-cased versions of the
same file (as windows sees them as 1 file and tries to get rid of the 
copy).  It can be reproduced on linux with any fs that allows

case-insensitivity (but may also be case preserving).  Besides xfs
having that for ascii since before xfs was on linux, I think 
some other FS's, zfs, maybe, and some planned future extensions

to existing file systems.   Again, don't know the status of this
bug either, but it might be related to how the case-insensitivity is
done in the file system implementing it.

Why do you have 'documents and settings' on your PC?  That went away
with XP and was replaced by 'Users'.  Is the local file system
NTFS?


--
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: [ITP] python3-configobj 5.0.6

[Yaakov Selkowitz]

On 2016-05-16 07:20, Mike DePaulo wrote:

This is the Python 3 complement to the Python 2 package of
python-configobj, which I uploaded last night.


Go ahead.  Thanks,

--
Yaakov

Re: Show Symbol Table for OMF (.obj)?

[Yaakov Selkowitz]

On 2016-05-16 14:10, Benjamin Cao wrote:

I am curious to know if there is a command that will display a symbol table for
*.obj files. It seems as if commands such as "nm" or "objdump" do not do this.
I get "File format not recognized".


You may want to try i586-pc-msdosdjgpp-{nm,objdump} from the 
djgpp-binutils package.


--
Yaakov

--
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: Show Symbol Table for OMF (.obj)?

[Warren Young]

On May 16, 2016, at 1:10 PM, Benjamin Cao  wrote:
> 
> I am curious to know if there is a command that will display a symbol table 
> for *.obj files. It seems as if commands such as "nm" or "objdump" do not do 
> this. I get "File format not recognized”.

nm *is* the right tool, but only for file types it knows about.

You should only expect a platform’s native nm to support the native executable 
types of the platform it runs on.  In the case of Cygwin, that’s various 
flavors of COFF and PE.  OMF is an entirely different format.

Cygwin’s nm happens to also support ELF for some reason, but that is yet a 
third object format.

Assuming libbfd knows OMF, you could rebuild your own OMF cross-development 
toolchain.  Then *its* nm would be the right tool for the job.

  https://en.wikipedia.org/wiki/Binary_File_Descriptor_library
--
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: Show Symbol Table for OMF (.obj)?

[Mark Geisert]

Benjamin Cao writes:
> I am curious to know if there is a command that will display a symbol 
table for *.obj files. It seems as if
> commands such as "nm" or "objdump" do not do this. I get "File format 
not recognized".
> 
> If there is a way to get it to work with nm or objdump, I am all ears. 
Or if there is a different command to satisfy
> this, that would be helpful as well.

Both nm and objdump are capable of displaying symbol tables.  The error 
message you're getting means you need to explicitly specify
"--target=BFDNAME" with BFDNAME matching the .obj file's format.

The formats we typically see are pe-i386 and pei-i386 for x86 object and 
image, and pe-x86-64 and pei-x86-64 for x86_64 object and image, 
respectively.

'nm --help' and 'objdump --help' show the supported targets.

..mark


--
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

Show Symbol Table for OMF (.obj)?

[Benjamin Cao]

Hi,

I am curious to know if there is a command that will display a symbol table for 
*.obj files. It seems as if commands such as "nm" or "objdump" do not do this. 
I get "File format not recognized".

If there is a way to get it to work with nm or objdump, I am all ears. Or if 
there is a different command to satisfy this, that would be helpful as well.

Thanks,
Ben Cao

--
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: Why does ldd not show cyg*.dll in its output?

[Marco Atzeri]

On 16/05/2016 17:42, Warren Young wrote:

STC:

$ ldd `which ls`

Actual output:

$ ldd `which ls`
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd16fb)
KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd16b8)
KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd13f5)

Expected output:

According to Microsoft’s Dependency Walker tool, the output should also list 
cygwin1.dll and cygintl-8.dll, at minimum.  Since it seems happy to chase 
dependencies from kernel32.dll to the other two, which are not explicit 
dependencies of ls.exe, it should also list cygiconv-2.dll, via cygintl.

Bonus points if the output changes to a tree view, so the indirect dependencies 
are clear.


it works as expected for me:

$ ldd /usr/bin/ls.exe
 ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7741)
 kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x771f)
 KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll 
(0x7fefd46)

 SYSFER.DLL => /cygdrive/c/Windows/System32/SYSFER.DLL (0x74e9)
 cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
 cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3e184)
 cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3e6e9)


$ objdump -x /usr/bin/ls.exe |grep "DLL Name:"
DLL Name: cygwin1.dll
DLL Name: cygintl-8.dll
DLL Name: KERNEL32.dll



--
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: Why does ldd not show cyg*.dll in its output?

[Yaakov Selkowitz]

On 2016-05-16 10:42, Warren Young wrote:

$ ldd `which ls`
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd16fb)
KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd16b8)
KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd13f5)


WFM:

$ /bin/ldd /bin/ls
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x77c9)
kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll 
(0x77a7)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll 
(0x7fefdb1)

cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x3d4e0)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x3d8b5)


Expected output:

According to Microsoft’s Dependency Walker tool, the output should also list
cygwin1.dll and cygintl-8.dll, at minimum.  Since it seems happy to chase
dependencies from kernel32.dll to the other two, which are not explicit
dependencies of ls.exe, it should also list cygiconv-2.dll, via cygintl.


See above.


Bonus points if the output changes to a tree view, so the indirect dependencies 
are clear.


ldd is meant to be compatible with the Linux tool.  As Andrey mentioned, 
use cygcheck instead if you want that layout.


--
Yaakov

--
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: Why does ldd not show cyg*.dll in its output?

[Warren Young]

On May 16, 2016, at 10:48 AM, Andrey Repin  wrote:
> 
> Greetings, Warren Young!
> 
>> STC:
> 
>>$ ldd `which ls`
> 
> $ cygcheck $(which ls)

Good to know.  But ldd should do it, too. :)

--
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: Why does ldd not show cyg*.dll in its output?

[Andrey Repin]

Greetings, Warren Young!

> STC:

> $ ldd `which ls`

> Actual output:

> $ ldd `which ls`
> ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd16fb)
> KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd16b8)
> KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd13f5)

> Expected output:

> According to Microsoft’s Dependency Walker tool, the output should also
> list cygwin1.dll and cygintl-8.dll, at minimum.  Since it seems happy to
> chase dependencies from kernel32.dll to the other two, which are not
> explicit dependencies of ls.exe, it should also list cygiconv-2.dll, via 
> cygintl.

> Bonus points if the output changes to a tree view, so the indirect 
> dependencies are clear.

$ cygcheck $(which ls)
C:\Programs\Cygwin_64\bin\ls.exe
  C:\Programs\Cygwin_64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
  C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
  C:\Windows\system32\ntdll.dll
  C:\Windows\system32\KERNELBASE.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
  C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
  C:\Programs\Cygwin_64\bin\cygintl-8.dll
C:\Programs\Cygwin_64\bin\cygiconv-2.dll

m?


-- 
With best regards,
Andrey Repin
Monday, May 16, 2016 19:47:22

Sorry for my terrible english...

Why does ldd not show cyg*.dll in its output?

[Warren Young]

STC:

$ ldd `which ls`

Actual output:

$ ldd `which ls`
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffd16fb)
KERNEL32.DLL => /c/WINDOWS/system32/KERNEL32.DLL (0x7ffd16b8)
KERNELBASE.dll => /c/WINDOWS/system32/KERNELBASE.dll (0x7ffd13f5)

Expected output:

According to Microsoft’s Dependency Walker tool, the output should also list 
cygwin1.dll and cygintl-8.dll, at minimum.  Since it seems happy to chase 
dependencies from kernel32.dll to the other two, which are not explicit 
dependencies of ls.exe, it should also list cygiconv-2.dll, via cygintl.

Bonus points if the output changes to a tree view, so the indirect dependencies 
are clear.
--
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

Permissions Problems

[Norton Allen]

I have seen problems similar to those reported in "RE: Possible issue 
with newest version of git (v 2.8) under Cygwin", but I did not want to 
hijack that thread.


For me, the problems have been elusive. Scripts that used to work would 
fail as created directories had bad permissions, but I didn't have time 
to sort them out. In the last week, I finally had time to read through 
the documentation on the ntsec page and try some tests, and of course 
now I'm having trouble reproducing the problems. You'd think that was a 
good thing, right?


I had been using /etc/passwd from mkpasswd, and based on recommendations 
here, I modified nsswitch for passwd: db. This seemed to work fine, and 
I decided I was all set.


Then Windows update rebooted over the weekend, and nothing worked, and 
returning to 'files' resolved the problem.


The exacerbating factor here is that I have a laptop connected to my 
work domain, but we use cached windows credentials when we are not on 
the work LAN (like at home over the weekend). In this scenario, cygwin 
was apparently unable to determine my username, and hence was unable to 
locate my home directory. The username is apparently cached successfully 
if I reboot at work and then go offline, but not if I reboot offline.


Does this mean I need to stay with 'passwd: files db' for the 
foreseeable future, or is it possible to find the username in this scenario?




--
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: Possible issue with newest version of git (v 2.8) under Cygwin

[andrew stern]

>>> If I leave off the noacl and do a clone followed by a push and pull
>>> we
>>> >end up with the following error in the Windows security tab:
>>> >   The permissions on file.cpp are incorrectly ordered, which may
>>> >cause some entries to be ineffective.
>> Yes, I've seen that before; it's a problem with the underlying
>> cygwind1.dll rather than a problem with Git.  I believe the consensus
>> from people on this list who know more about Windows permissions than
>> me is that the warning is actually benign and can be ignored.

>As I read the Cygwin documentation, the problem is that windows permissions 
>and POSIX permissions don't line up very well. In order to faithfully 
>reproduce POSIX permissions, Cygwin uses legal but non-standard ordering of 
>ACEs.
> Windows' security tab thinks this is a problem, but it really isn't. To quote 
> from the documentation here:
>https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files:

>Unfortunately the security tab in the file properties dialog of the
>Windows Explorer insists to rearrange the order of the ACEs to
>canonical order before you can read them. Thank God, the sort order
>remains unchanged if one presses the Cancel button. But don't even
>*think* of pressing OK...

> So it would seem the problem as such lies with Windows' security tab.

I would agree if it wasn't for the fact that even without looking at
the permissions tab we ended up with the inability for anyone else in
the group to write or update the head for the repository.  This is a
much bigger issue then just a display issue in Windows.  It is causing
read write permission issues where members can't push changes from
their local trees after another team member pushes their changes.  It
seems to mess it up in such a way that a system admin must reset
permissions after each push so that another team member can push their
changes.  This just started happening after updating cygwin in the
last few weeks and is related to changes to the ACL that were done in
the last couple of months.

--
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: Possible issue with newest version of git (v 2.8) under Cygwin

[andrew stern]

>To be absolutely clear: if you mount an NFS share with noacl set, you get a 
>noticable speed increase versus not setting noacl?
Let me clear this up a bit.  The group is working on local
repositories that happen to exist on local NTFS drives under Windows.
These drives are the same local drives that we make changes to before
pushing up the changes.  The local drives when mounted using the
default setting for cygwin is much slower then when we add noacl to
the fstab files mount line.  The NFS drives isn't accessed directly
except though git commands because we store our common repository on a
shared drive instead of running a git server like github or gitblit.

>> Although the repository
>> is on a NFS drive the local file system is NTFS and I see it spending
>> lots of time doing the update on the merge even though it is just a
>> couple of files that have changed.  I'm still trying to figure out
>> what exactly is going on and how best to deal with the permissioning
>> issue that we are now experiencing.  After discussions we would rather
>> have it slow then have bad permission problems but I'd rather not have
>> either issue.

>Am I correct in understanding you have multiple users trying to access the 
>same shared Git working repository?  I'm aware it's a workaround rather than 
>an actual >solution, but I'd expect you'd have better luck with each having a 
>separate working copy on your >local machine rather than sharing a common 
>working copy.

We do have local copies but we have to push our changes somewhere
after we change our local tree.  In this case it is a shared NFS
drive.

>> If I leave off the noacl and do a clone followed by a push and pull we
>> end up with the following error in the Windows security tab:
>>   The permissions on file.cpp are incorrectly ordered, which may cause
>> some entries to be ineffective.

>Yes, I've seen that before; it's a problem with the underlying cygwind1.dll 
>rather than a problem with Git.  I believe the consensus from people on this 
>list who
>know more about Windows permissions than me is that the warning is actually 
>benign and can be ignored.

The warning isn't benign in this case as it messes up the permissions
so that all the other team members no longer have write permissions so
that they can't check in their changes.   Before the recent ACL
changes to cygwin we worked without any issues and have been using git
and cygwin for years before these changes.

--
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

[ITP] python3-configobj 5.0.6

[Mike DePaulo]

This is the Python 3 complement to the Python 2 package of
python-configobj, which I uploaded last night.

https://github.com/mikedep333/python3-configobj-cygport

category: Python
requires: python3
sdesc: "Python module for handling config files"
ldesc: "ConfigObj is a simple but powerful config file reader and writer:
an ini file round tripper. Its main feature is that it is very easy to use,
with a straightforward programmer's interface and a simple syntax for config
files."

Re: Possible issue with chown v8.25

[Andrey Repin]

Greetings, lostbits!

Please don't top-post. Thank you.

> On 5/15/2016 6:16 PM, Andrey Repin wrote:
>> Greetings, lostbits!
>>
>>>  Click Reorder
>> Don't do that.
>>
>>>  This corrects the error.
>> No, it breaks permissions.
>>
>>> For the directory and contained subdirectories, the  is put into
>>> the "Group or user names" popup of the Security property. The 
>>> has no assigned permissions.
>>> The contained files in the directory have  in the "Group or user
>>> names" popup of the Security property. The  has all permissions
>>> except special permissions.
>>> Summary: When the chown -R command is given, the ownership and group of
>>> the directory and contained files are changed but the permissions of the
>>> directory are detected as incorrect by Win7.
>> Don't confuse Explorer and OS itself.
>>
>>> The owner has no
>>> permissions in the directory but does have permissions in the files
>>> contained in the directory.
>>> I don't think that this is something that I caused through a fault of my
>>> own. It looks like a chown bug.  Is there a workaround?
>> You didn't tell us, what is your problem.
>> You did not provide icacls and getfacl listings.

> Your English is fine - mine is problematical.

> What are icacls and getfacl listings?

icacls is a Windows tool to look at permissions.
getfacl is POSIX/Cygwin one.

> My problem is that after a chown the directories are inaccessible

Seeing exact permissions after change may help determine the culprit.

> and/or
> I can not look at the Security property without getting a diagnostic.
> I have assumed that the diagnostic indicates an issue. I get the feeling
> that the diagnostic does not indicate a fault and that things should 
> work fine.

> I just ran a minitest:

 >> mkdir gg
 >> touch gg/cc

icacls gg
getfacl gg

 >> chown -R : gg

icacls gg
getfacl gg

> In the Explorer I get the same diagnostic on gg and the  has no 
> permissions. Is this the correct behavior (and if you tell me what 
> icacls and getfacl listings I will provide them.

From your description, this doesn't look like correct behavior, but more
information may be necessary to find out, what's going wrong.

Do you have latest Cygwin installed?
Did you change default nsswitch settings?
Do you [still] have manual mapping in /etc/{passwd,group} ? (I strongly
suggest to get rid of both these files.)
Is this a domain member or standalone system?


-- 
With best regards,
Andrey Repin
Monday, May 16, 2016 13:35:37

Sorry for my terrible english...

How to install PHP apcu extension?

[Sky Diver]

Hi, I can't seem to find an answer on google nor the cygwin mailing lists.

I'd like to understand how could I add extensions, specifically -
apcu, to the php module.

Can someone help?

--
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