From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: stefanha@gmail.com, Xu Wang <cngesaint@gmail.com>,
Fam Zheng <famz@redhat.com>,
qemu-devel@nongnu.org, xiawenc@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH V2 0/5] Add infinite loop check for backing file chain
Date: Wed, 10 Jul 2013 11:20:48 -0600 [thread overview]
Message-ID: <51DD97F0.8060001@redhat.com> (raw)
In-Reply-To: <20130710114250.GM3898@dhcp-200-207.str.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
On 07/10/2013 05:42 AM, Kevin Wolf wrote:
>> Thanks for the series. I made a few comments on each patch. You hashed
>> windows full path to get the "inode", but case sensitively, would that
>> work with the same files of different case?
>
> I seem to remember that Windows can be made case-sensitive. In this
> case, we must not ignore case. Not detecting some loops is okay (but here
> we would in fact detect it in the second iteration), rejecting valid
> configurations is not.
Indeed, Windows can be made case-sensitive. But you still want to hash
case-insensitive, and just be careful to not report collisions until
after checking inode equality. For that matter, stat() on windows is
notoriously lame (such as returning 0 for st_ino on FAT, regardless of
file). While I've compiled on windows, it has generally been on cygwin
(where they go to great lengths to give a sane stat() in spite of FAT's
shortcomings); you may want to get a review from someone more intimately
acquainted with mingw (Paolo?), in case there is no way to make inode
equality work, and where you may be better off with absolute path name
comparison.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]
prev parent reply other threads:[~2013-07-10 17:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 7:26 [Qemu-devel] [PATCH V2 0/5] Add infinite loop check for backing file chain Xu Wang
2013-07-08 7:26 ` [Qemu-devel] [PATCH V2 1/5] Refine and export infinite loop checking in collect_image_info_list() Xu Wang
2013-07-10 10:25 ` Fam Zheng
2013-07-10 10:49 ` Fam Zheng
2013-07-12 2:58 ` Xu Wang
2013-07-08 7:26 ` [Qemu-devel] [PATCH V2 2/5] Add WIN32 platform support for backing_file_loop_check() Xu Wang
2013-07-10 10:44 ` Fam Zheng
2013-07-15 6:09 ` Xu Wang
2013-07-15 6:30 ` Fam Zheng
2013-07-08 7:26 ` [Qemu-devel] [PATCH V2 3/5] Check infinite loop in bdrv_img_create() Xu Wang
2013-07-10 10:52 ` Fam Zheng
2013-07-08 7:26 ` [Qemu-devel] [PATCH V2 4/5] Add backing file loop check in change_backing_file() Xu Wang
2013-07-10 10:57 ` Fam Zheng
2013-07-08 7:26 ` [Qemu-devel] [PATCH V2 5/5] Add infinite loop check in drive_init() Xu Wang
2013-07-10 11:00 ` Fam Zheng
2013-07-10 11:13 ` [Qemu-devel] [PATCH V2 0/5] Add infinite loop check for backing file chain Fam Zheng
2013-07-10 11:42 ` Kevin Wolf
2013-07-10 17:20 ` Eric Blake [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51DD97F0.8060001@redhat.com \
--to=eblake@redhat.com \
--cc=cngesaint@gmail.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=xiawenc@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).