Re: Cp can't hardlink unqualified wildcard

2012-10-20 Thread Lawrence Mayer
On 121020 12:35, Eric Blake wrote: On 10/20/2012 12:50 PM, Lawrence Mayer wrote: Cp can't hardlink unqualified wildcard cp -l * DIRECTORY fails with error 'cp: target `file' is not a directory' Most likely, this is not an error in cp, but a misunderstanding on your par

CP and Ln can't parse windows path ending in wildcard

2012-10-20 Thread Lawrence Mayer
CP and Ln can't parse windows path ending in wildcard e.g. ln WINDOWS PATH\* DIRECTORY (3rd form) ln -t DIRECTORY WINDOWS PATH\*  (4th form) cp -l WINDOWS PATH\* DIRECTORY all fail returning error message 'cannot stat `WINDOWS PATH\\*': No such file or directory' Workaround: ln WINDOWS PATH/*

Cp can't hardlink unqualified wildcard

2012-10-20 Thread Lawrence Mayer
Cp can't hardlink unqualified wildcard cp -l * DIRECTORY fails with error 'cp: target `file' is not a directory' But the equivalent cp -l ./* DIRECTORY AND cp -l PATH OF WORKING DIRECTORY/* DIRECTORY both appear to work fine. -- Problem reports: http://cygwin.com/problems.html FAQ:

Ln can't hard link into named directory

2012-10-20 Thread Lawrence Mayer
Ln can't hard link into named directory. e.g. Ln ... TARGET... DIRECTORY (3rd form) and ln ... -t DIRECTORY TARGET...  (4th form) both fail when DIRECTORY is named (but appear to work when DIRECTORY = '.' (current directory)) returning error message 'ln: Cannot create a file when that file

Re: [1.7] Cygwin 1.7 misnames hardlinks

2009-01-07 Thread Lawrence Mayer
On Wed, 7 Jan 2009, Corinna Vinschen wrote: The same happens with all hardlinks to files used by the system. The NT status code returned when trying to set the delete disposition flag is C121, STATUS_CANNOT_DELETE. None of the Windows native methods to delete these hardlinks works. I'm st

[1.7] Cygwin 1.7 misnames hardlinks

2008-12-23 Thread Lawrence Mayer
Cygwin 1.7-37 and -36 misname certain hardlinks by adding an extra .exe extention: e.g. ln vgaoem.fon .. creates vgaoem.fon.exe in the parent directory, not vgaoem.fon as expected. The same bug occurs with cp -l vgaoem.fon .. This bug occurs when hardlinking all .fon files I hav

Re: [1.7] Pipes intermittently lose data on Cygwin 1.7

2008-12-23 Thread Lawrence Mayer
On 081223 10:59, Christopher Faylor wrote: I'm uploading a new version of the DLL now. Please give it a try. It should be there in 5 - 10 minutes. http://cygwin.com/snapshots/ Bug appears fixed in current snapshot cygwin-inst-20081223! Thanks Christopher! I appreciate your work. I'm espec

Re: [1.7] Pipes intermittently lose data on Cygwin 1.7

2008-12-22 Thread Lawrence Mayer
On 081222 19:02, Allan Schrum wrote: Would it be worth trying to heavily load one of your computers to see if the problem presents itself differently? It is obvious that your systems are fast! Allan, at your suggestion, I repeated the trials on Computer 1 (details in previous post) under two

Re: [1.7] Pipes intermittently lose data on Cygwin 1.7

2008-12-22 Thread Lawrence Mayer
On 081222 16:48, Allan Schrum wrote: The numbers 5,132,288 and 5,138,895 are multiples of 4096. Thanks for writing Allan. I think you mean 5,132,288 and 5,136,384 (the two output sizes) are multiples of 4096. Lawrence: what is the hardware that your are running this test upon? What other p

Re: [1.7] Pipes intermittently lose data on Cygwin 1.7

2008-12-22 Thread Lawrence Mayer
Too bad. Since I can't duplicate the problem it will be difficult to fix it. Have you tried running the examples I provided in my original post (with foo = ~ 5MB text file) on a DOS shell (cmd.exe)? Yes. That's what I meant by "I can't duplicate the problem". Just ran current snapshot cy

Re: [1.7] Pipes intermittently lose data on Cygwin 1.7

2008-12-22 Thread Lawrence Mayer
On Sat, Dec 20, 2008 at 12:31:26PM -0800, Lawrence Mayer wrote: This bug appears specific to Cygwin 1.7 pipes on Win32 DOS (cmd.exe or command.exe). Cygwin 1.7 pipes on bash 3.2.48-21 or zsh 4.3.9-1 seem to work fine. On 081222 09:31, Christopher Faylor wrote: This may be fixed in the

Re: [1.7] Pipes intermittently lose data on Cygwin 1.7

2008-12-20 Thread Lawrence Mayer
This bug appears specific to Cygwin 1.7 pipes on Win32 DOS (cmd.exe or command.exe). Cygwin 1.7 pipes on bash 3.2.48-21 or zsh 4.3.9-1 seem to work fine. As mentioned in my previous post, this bug appears new to Cygwin 1.7 and not present in Cygwin 1.5.25-15. Greetings, Lawrence -- Unsubscr

[1.7] Pipes intermittently lose data on Cygwin 1.7

2008-12-20 Thread Lawrence Mayer
Pipes intermittently lose data on Cygwin 1.7.0-35 and -36. This bug appears generic to pipes under Cygwin 1.7 and not limited to any particular app. To reproduce this bug, create a ~ 5 MB text file foo. tr \32 \0 < foo | tr \0 \32 > bar should make bar = foo. But intermittently, bar is trunca

Re: Re: noacl functionality for MS-DOS destination paths?

2008-12-19 Thread Lawrence Mayer
On Dec 18 20:53, Lawrence Mayer wrote: Is there any way to get noacl functionality when using MS-DOS destination paths? My etc/fstab file (below) applies noacl for UNIX destination paths e.g. C:\cygwin\bin\mkdir.exe /c/foo creates directory C:\foo with NTFS default permissions inherited from

noacl functionality for MS-DOS destination paths?

2008-12-18 Thread Lawrence Mayer
Is there any way to get noacl functionality when using MS-DOS destination paths? My etc/fstab file (below) applies noacl for UNIX destination paths e.g. C:\cygwin\bin\mkdir.exe /c/foo creates directory C:\foo with NTFS default permissions inherited from parent directory C:\ (the same as DOS m