This is the mail archive of the
mailing list for the Cygwin project.
Re: "replaced while being copied" - was ... RE: Solved partially by findutils 4.3 - RE: "inode changed", ...
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 24 Jan 2006 13:10:25 +0100
- Subject: Re: "replaced while being copied" - was ... RE: Solved partially by findutils 4.3 - RE: "inode changed", ...
- References: <CCAC2F20421E784A87FAFDB3E0EC55720179FC89@DEVXCH1.brainlab.net>
- Reply-to: cygwin at cygwin dot com
On Jan 23 17:12, Jan Schormann wrote:
> You wrote on Monday, January 23, 2006 4:24 PM:
> > On Jan 23 13:34, Jan Schormann wrote:
> > > ...
> > Thanks. You didn't reply to my other question, though. What
> > filesystem exactly is on the remote side? I'm not familar with the
> > above combination
> > of values. This doesn't look like any native NTFS system, nor does it
> > look like a Samba share, AFAICS.
> to be honest, I haven't the faintest. This is a NetApp filer which
> is controlled by our IT staff. I will ask them, but I don't really
> expect any more concrete information than what you get when you
> google for "cifs site:netapp.com" (hints I gathered from within our
> intranet - cifs=common internet file system, looks like another M$
> invention), of which I just can't make any sense apart from this:
> The OS is called "Data ONTAP", and it is capable of exporting volumes
> as NFS and CIFS at the same time. CIFS volumes can then get NetBIOS
> aliases, which seems to be what I see from my client. The documentation
> mentions that the volumes on the filer are initially of type "FlexVol",
> which seems to be an invention of NetApp.
> This is probably not enough to understand what's happening here,
> particularly if you haven't got a NetApp filer around for testing.
> In that case I'm inclined to give up for now and apologize for the
> because I can live without cp'ing exes from the share.
No, I think that's enough for now. As suggested by somebody on this
list some weeks ago, I will change the condition on which I use the real
inode number instead of faking the inode number using a hash value
depending on the FILE_SUPPORTS_OBJECT_IDS flag, except for Samba file
systems. This should lower the chance to get unreliable inode numbers.
Otherwise, I'm always glad to get the file system flags returned by
other remote file systems, to raise the chance to get reliable inode
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html