On Jan 11 11:33, Nellis, Kenneth wrote:
From: Eric Blake
From here, Corinna probably has better insights into how to patch
cygwin1.dll to work around your broken file system (it isn't NTFS, even
though it claims to be, because NTFS has max filenamelength of 255 and
a
lot more TRUE flags
From: Corinna Vinschen
See the User's Guide here:
http://cygwin.com/cygwin-ug-net/using.html#mount-table
Try to mount the Q: drive with the ihash' option, for instance:
$ cat /etc/fstab.c/knellis EOF
Q: /qnx stone_age_old_samba binary,ihash 0 0
EOF
$ mount -a
That should
On Jan 12 08:09, Nellis, Kenneth wrote:
From: Corinna Vinschen
See the User's Guide here:
http://cygwin.com/cygwin-ug-net/using.html#mount-table
Try to mount the Q: drive with the ihash' option, for instance:
$ cat /etc/fstab.c/knellis EOF
Q: /qnx stone_age_old_samba
From: Corinna Vinschen
Erm... you have to use the /qnx path, rather than /cygdrive/q:
Okay, that worked! BTW, I tried the following...
Q: /cygdrive/q stone_age_old_samba binary,ihash 0 0
...but that didn't work; not sure why, but I suspect you know,
and that's why you proposed /qnx.
No idea
On 01/12/2011 10:17 AM, Nellis, Kenneth wrote:
Thanx for your help! I can live with /qnx although it'd be
nicer for /cygdrive/q to work so I don't have to change
my scripts.
(Untested idea): You could change your /cygdrive mount point to
/cygdrive-real via another fstab entry, then create a
On Jan 12 10:25, Eric Blake wrote:
On 01/12/2011 10:17 AM, Nellis, Kenneth wrote:
Thanx for your help! I can live with /qnx although it'd be
nicer for /cygdrive/q to work so I don't have to change
my scripts.
(Untested idea): You could change your /cygdrive mount point to
/cygdrive-real
On 01/11/2011 06:50 AM, Nellis, Kenneth wrote:
knel...@cobqdppj1 ~
$ cp /cygdrive/q/knellis/xyz .
cp: skipping file `/cygdrive/q/knellis/xyz', as it was replaced while being
copied
cp is different than tar. Downgrading tar won't help cp complaining
about unstable inodes.
Have you tried
On 01/11/2011 08:33 AM, Nellis, Kenneth wrote:
Curious why you put me on the tar path when my problem was originally
stated as being with cp. Regardless, the latest snapshot does not
change the result. Here are the current results, and cygcheck -svr
output is attached.
My bad - I was reading
From: Eric Blake
From here, Corinna probably has better insights into how to patch
cygwin1.dll to work around your broken file system (it isn't NTFS, even
though it claims to be, because NTFS has max filenamelength of 255 and
a
lot more TRUE flags - do you know if it is a NetApp device, or is
From: Eric Blake
On 01/07/2011 01:06 PM, Nellis, Kenneth wrote:
Using Cygwin 1.7.7, the following behavior started recently,
but I can't think of any change that may be the culprit:
I can. Most likely, you recently ran setup.exe and upgraded tar.
Indeed. :-)
Upstream tar includes a
On 1/10/2011 8:55 AM, Nellis, Kenneth wrote:
From: Eric Blake
On 01/07/2011 01:06 PM, Nellis, Kenneth wrote:
Using Cygwin 1.7.7, the following behavior started recently,
but I can't think of any change that may be the culprit:
I can. Most likely, you recently ran setup.exe and upgraded tar.
Would either of the following help?
-collect a network capture using Wildshark while running both the Cygwin
cp command and the Windows Explorer copy operation (or a simple Windows
cmd cp command).
-use Microsoft's Process Monitor to collect a Win32 trace while running
both the Cygwin cp
On 01/07/2011 01:06 PM, Nellis, Kenneth wrote:
Using Cygwin 1.7.7, the following behavior started recently,
but I can't think of any change that may be the culprit:
I can. Most likely, you recently ran setup.exe and upgraded tar.
Upstream tar includes a patch to make it more picky about
13 matches
Mail list logo
