Namjae Jeon <linkinjeon@xxxxxxxxx> writes: >> You have to think about compatibility with other FAT, not unix fs. > > Agreed, ctime is creation time, and there are comptability issues with > the patch. > > But there is confusion about 'ctime' usage in the default code. When > referring the code I found many instances except 'fat_fill_inode' > where 'ctime' is updated as if it is 'change time' instead of > 'creation time' like in functions: fat_write_end(), fat_cont_expend(), > fat_free(), vfat_add_entry(). > > As a case when I check using a simple case: > dd if=/dev/zero of=./samplefile bs=4096 count=10 > => check file timings > wait for 2minutes > Now, append to this file > echo "this is simple string to be appended" >> samplefile > => check file timings > > I can see - it resulted in change in 'ctime' and 'mtime'. > Now, when Connecting this Drive to Windows - it shows the time of > 'second write' as the CREATION time as well as "Modification time". > If you agree that this is a strange/problem. I can try to fix the > timestamp of linux FAT checking this compatability pattern to the > nearest. > Let me know your opinion. Yes. It is strange behavior, and it is what I was calling historical. If we changed this behavior now, user can be notice to change of historical behavior. Also, if we didn't change this, it is strange as FAT-fs compatibility. If I can design from scratch, probably I will choose FAT-fs compatibility at first. But we can't, and I don't have strong opinion to change current behavior. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> -- 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
