Most recent kernel where this bug did not occur: not known Distribution: Fedora Core 5 with updates Hardware Environment: this bug doesn't depepend on hardware Software Environment: Wine/Cedega/Crossover Office + Heroes of Might and Magic 3 game Problem Description: The mentioned game installed on FAT32 partition and run in any Wine flavour creates (through Wine, of course) save game files which cannot be read/deleted/whatever even under root user; ls -l gives this directory listing: games]# ls -l total 608 ?--------- ? ? ? ? ? 002.cgm ?--------- ? ? ? ? ? 003.cgm ?--------- ? ? ? ? ? 004.cgm ?--------- ? ? ? ? ? 005.cgm ?--------- ? ? ? ? ? 006.cgm -r--r--r-- 1 root root 110806 Jun 1 07:03 20end.cgm -rw-rw-rw- 1 root root 81085 Jun 1 22:17 21end.cgm -rw-rw-rw- 1 root root 77490 Jun 2 00:30 22end.cgm -rw-rw-rw- 1 root root 168727 Jun 4 20:02 a.CGM -rw-rw-rw- 1 root root 167510 Jun 4 20:32 autosave.cgm Steps to reproduce: Install this game on FAT32 partition; play and save your games in different files. Upon this FAT32 partition remount all files are OK.
Probably, it seems stat(2) returned a error, but getdents(2) (readdir(3)) didn't return error. If so, it may indicates filesystem is already corrupted... Could you send the following log[123] to reproduce this bug on my machine? # cat /proc/mounts > /tmp/log1 # strace -fF -o /tmp/log2 probram_to_reproduce_bug do remount # cat /proc/mounts > /tmp/log3 Also, can you try dosfsck after backup?
I'm not sure I can strace wine running another application but I will try. As for fsck'ing - the FS is OK - I've checked it both with Windows XP chkdsk and Linux fsck.vfat. [root@localhost ~]# fsck.vfat -vVr /dev/hdb1 dosfsck 2.11 (12 Mar 2005) dosfsck 2.11, 12 Mar 2005, FAT32, LFN Checking we can access the last sector of the filesystem Boot sector contents: System ID "MSDOS5.0" Media byte 0xf8 (hard disk) 512 bytes per logical sector 8192 bytes per cluster 36 reserved sectors First FAT starts at byte 18432 (sector 36) 2 FATs, 32 bit entries 7334912 bytes per FAT (= 14326 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 14688256 (sector 28688) 1833629 data clusters (15021088768 bytes) 63 sectors/track, 255 heads 63 hidden sectors 29366757 sectors total Starting check/repair pass. Checking for unused clusters. Checking free cluster summary. Starting verification pass. Checking for unused clusters. /dev/hdb1: 1590 files, 577191/1833629 clusters [root@localhost ~]# echo $? 0
Thanks. There is no corruption. Umm.. Could you send log of: # strace -o /tmp/log ls -l It should tell why LS displays the strange `?'. BTW, If strace doesn't work for wine, let me know. I'll make a patch for debugging this instead.
Recently I had had to reformat this partition and after that I cannot get this bug symptoms.
Created attachment 8290 [details] strace -o ls.log ls -l Here's a log your've requested.
Here's how this partition is mounted: /dev/hda1 /mnt/ext vfat rw,noatime,fmask=0000,dmask=0000,codepage=cp866,iocharset=utf8,showexec 0 0
Created attachment 8291 [details] debug patch
Thanks. stat(2) returns a error. It's strange. Umm... it may be a miss handling bug of dentry. Or it may be related to iocharset=utf8 option, but in the case of those filenames, it should be ok. Could you try attached debugging patch? create files, "ls -l", and after that, please send dmesg.
Created attachment 8311 [details] dmesg
Created attachment 8312 [details] dmesg run just after `ls -l` in that folder
ls -l total 40 -rw-rw-rw- 1 root root 34351 Jun 15 03:45 001.cgm ?--------- ? ? ? ? ? autosave.cgm
This is very strange, and interesting. From strace's log, `ls' seems to pass "autosave.cgm" to lstat64, but actually it was passed to vfat as "(null)". More debugging code would be needed..., sorry. I'll make patch again at this weekend.
Created attachment 8330 [details] debug patch2 I added the printk() to upper layer of vfat. I'm not sure, but hopefully, this will make clear what is wrong. Please try this patch, then send "dmesg -s 100000" and "strace -v ls -l".
The bug is not reproducible when vfat is compiled as a module. I'll investigate futher later.
I cannot reproduce this bug on kernels >= 2.6.18, thus let's mark it closed.