Mike Mascari wrote:
> > foo contains: "FOO"
> > bar contains: "BAR"
> >
> > 1. Process 1 opens "foo"
> > 2. Process 2 opens "foo"
> > 3. Process 1 calls MoveFile("foo", "foo2");
> > 4. Process 3 opens "foo" <- Successful?
> > 5. Process 1 calls MoveFile("bar", "foo");
> > 6. Process 4 opens "foo"
Mike Mascari wrote:
> Its interesting in that it allows for Unix-style rename() and
> unlink() behavior, but with a race condition. Without Stephan's
> two MoveFile() trick and the FILE_SHARE_DELETE flag, however,
> the result would be Access Denied. Are the places in the backend
> that use re
I wrote:
> Stephan Szabo wrote:
>>
>> The question is, what happens if two people have the file open
>> and one goes and tries to delete it? Can the other still read
>> from it?
>
> Yes. I just tested it and it worked. I'll test Bruce's scenario as well:
>
> foo contains: "FOO"
> bar contains:
Stephan Szabo wrote:
> On Fri, 20 Sep 2002, Mike Mascari wrote:
>
>
>>I think that's a rather poor description. I think it just means
>>that if the file is opened once via CreateFile() with
>>FILE_SHARE_DELETE, then any subsequent CreateFile() calls will
>>fail unless they too have FILE_SHARE_DE
Mike Mascari wrote:
> instead of fopen(). I'm not sure about ME, but I suspect it
> behaves similarly to 95/98.
I just checked with Katie and the good news (tm) is that the Win32 port
we did here at PeerDirect doesn't support 95/98 and ME anyway. It does
support NT4, 2000 and XP. So don't bother
Mike Mascari wrote:
> Bruce Momjian wrote:
> > I don't think we are not going to be supporting Win9X so there isn't an
> > issue there. We will be supporting Win2000/NT/XP.
> >
> > I don't understand FILE_SHARE_DELETE. I read the description at:
> >
> >
>http://msdn.microsoft.com/library/
On Fri, 20 Sep 2002, Mike Mascari wrote:
> Bruce Momjian wrote:
> > I don't think we are not going to be supporting Win9X so there isn't an
> > issue there. We will be supporting Win2000/NT/XP.
> >
> > I don't understand FILE_SHARE_DELETE. I read the description at:
> >
> >
>http://msdn.mi
Bruce Momjian wrote:
> I don't think we are not going to be supporting Win9X so there isn't an
> issue there. We will be supporting Win2000/NT/XP.
>
> I don't understand FILE_SHARE_DELETE. I read the description at:
>
>
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/f
I don't think we are not going to be supporting Win9X so there isn't an
issue there. We will be supporting Win2000/NT/XP.
I don't understand FILE_SHARE_DELETE. I read the description at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp
but
Stephan Szabo <[EMAIL PROTECTED]> writes:
> ... let you do the replace and keep reading (at the penalty that
> you've now got to have a way to know when to remove the
> various s)
That is the hard part. Mike's description omitted one crucial step:
6. The old "foo" goes away when the last open f
Stephan Szabo wrote:
> On Fri, 20 Sep 2002, Mike Mascari wrote:
>>
>>Yes! Indeed that does work.
>
>
> Thinking back, I think that may still fail on Win95 (using MoveFile).
> Once in the past I had to work on (un)installers for Win* and I
> vaguely remember Win95 being more strict than Win98 but
On Fri, 20 Sep 2002, Mike Mascari wrote:
> Stephan Szabo wrote:
> > On Fri, 20 Sep 2002, Mike Mascari wrote:
> >>So far, MoveFileEx("foo", "bar", MOVEFILE_REPLACE_EXISTING)
> >>returns "Access Denied" when Process 1 attempts the rename. But
> >>I'm continuing to investigate the possibilities...
>
Stephan Szabo wrote:
> On Fri, 20 Sep 2002, Mike Mascari wrote:
>>Bruce Momjian wrote:
>>>Mike Mascari wrote:
Actually, looking at the pg_pwd code, you want to determine a
way for:
1. Process 1 opens "foo"
2. Process 2 opens "foo"
3. Process 1 creates "bar"
4. Process
On Fri, 20 Sep 2002, Mike Mascari wrote:
> Bruce Momjian wrote:
> > Mike Mascari wrote:
> >
> >>Actually, looking at the pg_pwd code, you want to determine a
> >>way for:
> >>
> >>1. Process 1 opens "foo"
> >>2. Process 2 opens "foo"
> >>3. Process 1 creates "bar"
> >>4. Process 1 renames "bar"
Bruce Momjian wrote:
> Mike Mascari wrote:
>
>>Actually, looking at the pg_pwd code, you want to determine a
>>way for:
>>
>>1. Process 1 opens "foo"
>>2. Process 2 opens "foo"
>>3. Process 1 creates "bar"
>>4. Process 1 renames "bar" to "foo"
>>5. Process 2 can continue to read data from the op
Mike Mascari wrote:
> Actually, looking at the pg_pwd code, you want to determine a
> way for:
>
> 1. Process 1 opens "foo"
> 2. Process 2 opens "foo"
> 3. Process 1 creates "bar"
> 4. Process 1 renames "bar" to "foo"
> 5. Process 2 can continue to read data from the open file handle
> and get
Mike Mascari wrote:
> Bruce Momjian wrote:
>
>> Mike Mascari wrote:
>>
>>> I will do some testing with concurrency and let you know. But don't
>>> get your hopes up. This is one of the many advantages that
>>> TABLESPACEs have when more than one relation is stored in a single
>>> DATAFILE. The
Bruce Momjian wrote:
> Mike Mascari wrote:
>
>>I will do some testing with concurrency and let you know. But
>>don't get your hopes up. This is one of the many advantages that
>>TABLESPACEs have when more than one relation is stored in a
>>single DATAFILE. There was Oracle for MS-DOS, after al
Mike Mascari wrote:
> I read the article and did not come away with that conclusion.
> The article describes using the MOVEFILE_DELAY_UNTIL_REBOOT
> flag, which was created for the express purpose of allowing a
> SETUP.EXE to remove itself, or rather tell Windows to remove it
> on the next reb
Bruce Momjian wrote:
> Bruce Momjian wrote:
>>>
>>>unlink() just calls DeleteFile() which will error if:
>>>
>>>1. The target file is in use
>>>
>>>CreateFile() has the option:
>>>
>>>FILE_FLAG_DELETE_ON_CLOSE
>>>
>>>which might be able to be used to simulate traditional unlink()
>>>behavior.
>>
Bruce Momjian wrote:
> > > Second, when you unlink() a file on Win32, do applications continue
> > > accessing the old file contents if they had the file open before the
> > > unlink?
> > >
> >
> > unlink() just calls DeleteFile() which will error if:
> >
> > 1. The target file is in use
> >
>
Mike Mascari wrote:
> Bruce Momjian wrote:
> > I am working with several groups getting the Win32 port ready for 7.4
> > and I have a few questions:
> >
> > What is the standard workaround for the fact that rename() isn't atomic
> > on Win32? Do we need to create our own locking around the
> > r
Christopher Kings-Lynne wrote:
>>On Wed, Sep 18, 2002 at 08:01:42PM -0400, Bruce Momjian wrote:
>>
>>
>>>Second, when you unlink() a file on Win32, do applications continue
>>>accessing the old file contents if they had the file open before the
>>>unlink?
>>
>>I'm pretty sure it errors with 'file
Bruce Momjian wrote:
> I am working with several groups getting the Win32 port ready for 7.4
> and I have a few questions:
>
> What is the standard workaround for the fact that rename() isn't atomic
> on Win32? Do we need to create our own locking around the
> reading/writing of files that are n
> On Wed, Sep 18, 2002 at 08:01:42PM -0400, Bruce Momjian wrote:
>
> > Second, when you unlink() a file on Win32, do applications continue
> > accessing the old file contents if they had the file open before the
> > unlink?
>
> I'm pretty sure it errors with 'file in use'. Pretty ugly, huh?
Yeah
On Wed, Sep 18, 2002 at 08:01:42PM -0400, Bruce Momjian wrote:
> Second, when you unlink() a file on Win32, do applications continue
> accessing the old file contents if they had the file open before the
> unlink?
I'm pretty sure it errors with 'file in use'. Pretty ugly, huh?
Ross
-
I am working with several groups getting the Win32 port ready for 7.4
and I have a few questions:
What is the standard workaround for the fact that rename() isn't atomic
on Win32? Do we need to create our own locking around the
reading/writing of files that are normally updated in place using
re
27 matches
Mail list logo
