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
> /cygd
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
> 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 id
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_ag
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
>
>
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
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, o
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 rea
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 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.
> 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 inclu
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 stat
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 "c
13 matches
Mail list logo
