On 2007.04.25 at 01:55:23 -0700, David Schwartz wrote: > > > For example, if we are running under Unix-style kernel, we can make > > stat calls on both files. And if both st_dev and st_ino fields of > > the resulting stat structures are same, we should consider files same. > > Why? Suppose the filesystem internally uses inodes larger than the st_ino > field. Is it guaranteed that a matching st_dev and st_ino field means the > files are the same? Where is this guarantee?
Because these fields are intended for that very purpose we are using it. So, if some operating system doesn't do it this way, it may be considered bug in OS. > Suppose the filesystem uses internal file versioning and the output file is > a new version of the input. Will they have the same inodes or different > ones? Do you know? I sure don't. (And I could think of reasons to do it > either way.) This should be conceptually considered overwriting file and require same syntax. Any way, report an error is much better than silently corrupt the file trying to read unencrypted data and write encrypted data into it same time. > Trying to keep the user from shooting himself in the foot risks shooting the > user in the foot even when he did not ask. User can easily work around this check using IO redirection, so there is nothing wrong with too much strictness. > > If we are running under DOS/Windows kernel, it is impossible to delete > > open file. So, if we open input file, we can than try to unlink output > > file, and if this fails, we should consider this fatal error (not > > neccessary files are same, but it is not safe to write to this file > > anyway) > > Why unlink the output file if the user didn't ask us to do that? That could > destroy version history the user wanted to keep. Yes, this is valid reason. It is not good to perform destructive operation just for checking purpose. But DOS/Windows systems since DOS 2.0 have mandatory file locking (and OpenSSL wouldn't work on DOS 2.0 and early anyway). So, if we open input file in deny write mode (User has asked us to read contents of this file hasn't he?) and then try open output file in write mode, we should get sharing violation. > You can perhaps solve this problem by adding complexity, but the problem is > that you are forcing the user to to anticipate your "smart algorithm", how Why anticipate? It should be documented. I think that saving user from common mistake which can destroy data, deserves adding a bit of complexity which may require some workaround in rare cases. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
