blob: b60e50b9cf4e422ba81810f66bd1fe63508e1851 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
exfat_core.c - ffsReadFile - the goto err_out seem to leak a brelse().
same for ffsWriteFile.
exfat_core.c - fs_sync(sb,0) all over the place looks fishy as hell.
There's only one place that calls it with a non-zero argument.
Randomly removing fs_sync() calls is *not* the right answer, especially
if the removal then leaves a call to fs_set_vol_flags(VOL_CLEAN), as that
says the file system is clean and synced when we *know* it isn't.
The proper fix here is to go through and actually analyze how DELAYED_SYNC
should work, and any time we're setting VOL_CLEAN, ensure the file system
has in fact been synced to disk. In other words, changing the 'false' to
'true' is probably more correct. Also, it's likely that the one current
place where it actually does an bdev_sync isn't sufficient in the DELAYED_SYNC
case.
ffsTruncateFile - if (old_size <= new_size) {
That doesn't look right. How did it ever work? Are they relying on lazy
block allocation when actual writes happen? If nothing else, it never
does the 'fid->size = new_size' and do the inode update....
ffsSetAttr() is just dangling in the breeze, not wired up at all...
|
