On 2007.04.20 at 11:57:35 -0700, David Schwartz wrote: > > > On 2007.04.19 at 11:59:39 -0700, David Schwartz wrote: > > > > > This is not nearly as simple as you might think. Are 'foo.txt' > > and 'Foo.txt' the same file? What about 'directory/file.txt' and > > 'symlink/file.txt'? > > > > > > I don't see how you can do this without making assumptions about the > > > semantics of the filesystem involved. These assumptions will sometimes > > > > I don't see why these assumptions cannot be done at compile time. > > There exists few different filesystem semanctics: > > The filesystem is not known at compile time.
No need to > > Unix one, > > DOS/Windows one, > > VMS (versioned) one. > > These are *OS* semantics. Linux, for example, supports filesystems with Unix > semantics, DOS (case-insensitive) semantics, and versioned filesystems. Operating system kernel provides suitable level of isolation. 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. If DOS-style filesystem is mounted locally or remotely under Unix-style OS, we can rely on OS kernel for emulation of that much of Unix filesystem semantics. 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) This is why I proposed my three-step approach 1. Check if input and output looks same, and if so report error. 2. Use special syntax if user really want to override input file with encrypted data 3. If this special syntax is used, take some steps to avoid leaving of unencrypted copies laying around. With this approach step 1 can be made robust enough with technique, described above. And it seems to me, that step 3 also can be implemented so it would work in 99.9% cases without digging into filesystem-specific things. Only dubious case is versioned file system (like VMS) mounted under Unix or DOS/Windows. It can just hide version mechanism from remote system. At least I don't remember tools which allow to manipulate versions of files from DOS DECnet client. But system which works in most often used cases and has clearly documented list of exceptions is better than no check at all. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
