Windows native and system copy

[GCC Consulting]

> -----Original Message-----
> From: 
> filepro-list-bounces+gcc=optonline.net at lists.celestial.com 
> [mailto:filepro-list-bounces+gcc=optonline.net at lists.celestial
.com] On Behalf Of Brian K. White
> Sent: Wednesday, March 23, 2005 2:41 AM
> To: filePro mailing list
> Subject: Re: Windows native and system copy
> 
> 
> ----- Original Message -----
> From: "GCC Consulting" <gcc at optonline.net>
> To: "'Kenneth Brody'" <kenbrody at bestweb.net>; "'Nancy Palmquist'" 
> <nlp at vss3.com>
> Cc: "'Filepro 2 List'" <filepro-list at lists.celestial.com>
> Sent: Tuesday, March 22, 2005 9:47 PM
> Subject: RE: Windows native and system copy
> 
> 
> >
> >
> >> -----Original Message-----
> >> From: filepro-list-bounces at lists.celestial.com
> >> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf
> >> Of Kenneth Brody
> >> Sent: Tuesday, March 22, 2005 10:31 AM
> >> To: Nancy Palmquist
> >> Cc: Filepro 2 List
> >> Subject: Re: Windows native and system copy
> >>
> >> Quoting Nancy Palmquist (Tue, 22 Mar 2005 10:15:56 -0500):
> >> [...]
> >> > Ken,
> >> >
> >> > While I understand you always work in a world where the OS works
> >> > perfectly,
> >>
> >> True.  On the other hand, what's going to happen when the
> >> system bug requires a 6-second delay to work around?  ;-)
> >>
> >> --
> >> KenBrody at BestWeb dot net        spamtrap:
> > Ken,
> >
> > Change the sleep to 6000 or something longer.
> >
> > All that aside, the file I am copying is there, the problem 
> is, I think, 
> > that
> > the OS still has it locked.  It is "taking its own sweet 
> time" to release 
> > it for
> > other uses. :)
> >
> > Maybe this wouldn't be a problem if I ran the task from on of the XP
> > workstations that are never shut
> > off.  Maybe the network latency would compensate for any 
> problems with the 
> > task
> > manager.
> >
> > Richard
> 
> Don't laugh.
> A one second delay may actually BE the most technically 
> correct answer 
> because it may actually be what windows itself does.
> 
> I just read a very interesting comment in a Linux magazine 
> article in an 
> interview with a lead maintainer of Samba 3.x who works for HP.
> 
> Basically, the interviewer made a whimsical comment/prompt 
> along the lines 
> of "bug for bug compatible with windows?" and the Samba 
> developers response 
> was to describe just one example (presumably of many) of 
> something they 
> found where their code initially performed exactly according to all 
> published specs. And yet, sometimes Excel will choke on a 
> file shared via 
> Samba, claiming it was open by someone else when it really wasn't.
> What they found was that Excel was opening the file, getting 
> an oplock, and 
> then opening the file again right away without having 
> released the first 
> lock, violating it's own lock. Samba was quite sanely 
> reporting a sharing 
> violation on that second attempted open. Why does it only 
> crash when the 
> file is hosted via Samba and not when hosted on a Windows 
> share? Because 
> Windows does NOT generate a sharing violation for the 2nd 
> open as long as 
> the first open closes within one second. He said that behavior isn't 
> documented *anywhere* and they've also found differences 
> between win2k and 
> 2k3 that indicate that sambas regression testing procedures 
> are apparently 
> more thorough than windows' own, else they'd have spotted the same 
> differences and either corrected or documented them.
> 
> The article is here:
> LinuxUser, Issue 46, page 47.
> 
> The cover looks like this, it's probably still on some 
> shelves, I just got 
> it today at a B&N, but it actually one issue old.
> http://www.linuxuser.co.uk/index.php?option=com_content&task=v
iew&id=58
> 
> Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani

Brian,

"Interesting - very interesting" :)

Richard