On Fri, May 2, 2008 at 11:56 AM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> However, as we have gained experience with the VFS, we have come to > realize that the original VFS design has some warts. In particular, > not all of the methods in the VFS interface are able to return the > errors that some systems want to return. For example, the xAccess() > method is used to determine whether or not a file exists. On Unix and > win32, the system calls to determine whether or not a file exists > cannot fail as long as the call is well-formed (i.e. you give it a > valid file descriptor.) The operating system will always be able to > give you a straight yes/no answer about whether or not a file exists. > And so we made no provisions in the VFS design for the xAccess() > method to return an error code. Since then, we have found that some > embedded platforms do not work this way and that it is sometimes > necessary for xAccess() to fail and say "I don't know". This can > happen, for example, when the system is unable to allocate memory for > an IPC buffer. If you're going to be making changes in this area anyway... The use of access() at all is really quite dangerous. It causes a race condition. It is quite possible that at the time that access() is called, a file can not exist, and when the file is then opened for creation, it can already have been created by a different process (or vice versa). It is much safer to never use access() to determine whether you "can" do something, but rather to actually try to "do" the operation, and test for success or failure. This avoid the possible race. Cheers, Derrell _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
