Search Postgresql Archives

Re: [HACKERS] Checkpoint request failed on version 8.2.1.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > I find it very unlikely that you would "during normal operations"
end up
> > in a situation where you would first have permissions to create
files in
> > a directory, and then lose them.
> > What could be is that you have a directory where you never had
> > permissions to create the file in the first place.
> 
> > Any chance to differentiate between these?
> 
> The cases we're concerned about involve access to an existing file,
not
> attempts to create a new one, so I'm not clear what your point is.

I am wondering if we can delete the file by opening it with
FILE_FLAG_DELETE_ON_CLOSE, and immediately close it again. 
The semantics should be clear if we let the OS delete the file after the

last handle on it is closed ? 
Until all handles are closed another process can still open it with 
FILE_SHARE_DELETE (according to docs), but not without the flag.
This seems to be what we want.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/
fs/createfile.asp

If this fails (see the loop in dirmod.c) we could try to move it to
the recycle bin with SHFileOperation with FO_DELETE.

It seems the win unlink is not implemented correctly and we need to
replace it.
I don't feel easy with the ignore EACCES idea. 

Should I try to supply a patch along this line ?

Andreas


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux