On Fri, Nov 15, 2013 at 10:21:40AM -0700, Eric Blake wrote: > On 11/15/2013 09:42 AM, Max Reitz wrote: > > > Actually, the same problem can occur anyway if you have a path with a > > couple of “.” and “..” in it – or even just a hardlink. Thus, to be > > completely safe, we'd have to check whether the snapshot file (if it > > already exists) has a different inode number and/or is located on a > > different filesystem. > > See also the recent thread on detecting backing file loops - this should > be part of that solution (if it isn't already): > https://lists.gnu.org/archive/html/qemu-devel/2013-11/msg01840.html > > > Backing file loops might get away with string-only detection; but then I > start to worry that the string-only detection will misbehave on relative > paths (consider: /dir1/a <- /dir1/b [backed by relative 'a'] <- /dir2/a > [backed by absolute /dir1/b] <- /dir2/a [backed by relative 'a']); > devno/inode pairs are the only reliable to detect loops when only the > filesystem is involved, but then you also introduce network protocols > (and there, it's worse: gluster://host1/vol/img and > gluster://host2/vol/img could be the same file, if host1 and host2 are > part of the same storage cluster, but there is no devno/inode to tell > you that).
Detecting identical "files" is not a problem that can be solved in the general case. Once network storage comes into play we don't have the ability to check file identity. Users can misconfigure QEMU if they try hard enough. Filename string manipulation is very error-prone and I'd rather just avoid it than provide a false sense of security. What's the real use case for this patch? Stefan
