Hi Sergei, On 16 Oct 2014, at 16:07, Sergei Antonov <saproj@xxxxxxxxx> wrote: > I looked at your code and do not quite understand the handling of > initialized size. You read it into a local copy while holding the > lock, but then after the lock is released it may change and, I'm > afraid, cause the same problems you mentioned. Correct. That is why FIBMAP is a stupid interface! However initialized_size can only ever go up and not down so in the worst case you will get result zero, i.e. hole instead of the now real sector number you could access. The only time it can shrink is when the file size shrinks and I am afraid if anyone is using FIBMAP against a file that can be truncated they will corrupt the file system! > What is an example of a platform with 32-bit sector_t? Interesting to know. Any 32-bit system that does not configure the kernel for 64-bit sector_t. Sorry can't remember the .config option name at the moment. Would need to look it up. > Is it really possible that ntfs_bmap() is called for non-data > attributes? In other words, what other attributes are accessible as > files? Just curious. I admit in current kernel driver it cannot. It might in future - reparse points for example are very odd in many ways and though they are often indicated as directories rather than files they could not always be and what attributes a reparse point has is anyones guess - depends on the reparse point. Then there are system files that do not have an unnamed $DATA attribute at all so in a way the check should probably be extended to ensure the attribute is $DATA _and_ unnamed but again anyone using FIBMAP on a system file is asking to cause problems... Best regards, Anton -- Anton Altaparmakov <anton at tuxera.com> (replace at with @) Senior Kernel Engineer, Tuxera Inc., http://www.tuxera.com/ Linux NTFS maintainer -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
