Messages in this thread | | | Date | Tue, 09 Aug 2005 09:32:24 +0900 | From | "Machida, Hiroyuki" <> | Subject | Re: [PATCH] Posix file attribute support on VFAT |
| |
Bodo Eggert wrote: > Hiroyuki Machida <machida@sm.sony.co.jp> wrote: > > >>For newly created and/or modified files/dirs, system can utilize >>full posix attributes, because memory resident inode storage can >>hold those. After umount-mount cycle, system may lose some >>attributes to preserve VFAT format. > > > Inodes may be reclaimed, therefore you might also lose some attributes at > runtime. For your users, that will look like a heisenbug. A similar bug > has been reported for procfs. Is your implementation affected?
Yes. Thank you, pointed it out. So I need to select 1) restric attribute even in mamory or 2) pinn inode in memory during mount (I think it's not good idea)
I'll revise the patch with 1).
>>- Special file >> To distinguish special files, look if this fat dir entry >> has ATTR_SYS, first. If it has ATTR_SYS, then check >> 1st. LSB bit in ctime_cs, refered as "special file flag". >> If set, this file is created under VFAT with "posix_attr". >> Look up TYPE field to decide special file type. >> This spcial file detection mothod has some flaw to make >> potential confusion. E.g. some system file created under >> dos/win may be treated as special file. However in most case, >> user don't create system file under dos/win. > > > You can add additional magic, e.g.: nodes must be empty, except for symlinks > which must be not larger than 4KB (current PATH_MAX?). This will get rid > of io.sys, logo.sys etc.\. If you want to be really sure, prepend a magic > code to the on-disk representation of symlinks.
Please confirm my understanding. You sugessted that symlink should not have ATTR_SYS, to prevent some over 4KB files created in DOS/WIN to be treated as symlinks?
-- Hiroyuki Machida machida@sm.sony.co.jp SSW Dept. HENC, Sony Corp. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |