-
Notifications
You must be signed in to change notification settings - Fork 6
/
TODO.txt
79 lines (74 loc) · 5.41 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
TODO list
Roadmap:
Symlinks
File locking and unlocking callbacks
File security callback
XATTRs
Remove Dokan callbacks that should never be called
Multi-drive volumes
Extended attributes?
Preallocated files (torrents maybe)
Data corruption resiliency (detect checksum issues and read from other copies if possible)
Concurrent callback support (threadsafety)
GUI (C#: which .NET version?)
Installer (NSIS)
MinGW/Cygwin[/Mono] build support
UI translations
OS testing: Win9x and ReactOS (provided Dokan supports these)
Tests:
Symlinks to files and directories
Cross-subvolume symlinks
Verify that unicode path strings don't result in a crash
Try to hit all the outward-facing filesystem interfaces (especially btrfs_operations.c) with extra-long strings for buffer overrun testing
Test weird node/sector/leaf sizes
Check for endianness errors by reversing byte orders on disk or running on a BE architecture (Wine on PPC Linux??)
Determine if, when a subvolume (B) is created within another subvolume (A), the ROOT_REFs have 0x5->A, and A->B, thwarting tree dumping,
possibly among other things that assume that these trees will have tree 0x5 as their parent
Write an fopen (or Win32) test to determine if CREATE_ALWAYS or OPEN_ALWAYS will ever get passed to btrfsCreateFile
Try different Win32 apis (specifically ones that correspond with callbacks that should NEVER BE CALLED) and see if eliciting a crash
is possible; also, see if removing the callbacks (putting NULL in the callback array) does what we ultimately want
Mount a test image in SSD mode and then see if WinBtrfs uses a secondary superblock
Bugs:
Mounting btrfs_symlinks.img to C:\mount and dirlisting C:\mount\dir results in a getPathID failure
Dirlisting an empty subvolume (e.g. X:\a2 or X:\a1\b2 in btrfs_nestsubvol.img) results in a FSOP_DIR_LIST failure
(this seems to be related to the fact that Windows expects '.' and '..' for every directory other than '\', but
the new subvolume code elides the '.' and '..' for every SUBVOL's root (so X:\a2 returns no '.' and '..' but it should)
Profile:
Check out how bad my overuse of realloc really is
Code stuff:
Add overflow checks for program arguments
Check for memleaks with valgrind
Rectify inconsistent struct member names: num/nr, csum/cSum/crc32c/etc, generation/gen, objectID/objID, len/length
Rectify inconsistent function arg names: len/length, addr/lAddr/logicalAddr/physAddr/etc, super/SB/superblock
Multithread support for everything: make block reading threadsafe, and ensure that calls to btrfs_operations.cpp functions
from different threads do not use any shared state
Check all malloc/realloc calls and end fatally upon malloc failure (return win32 equivalent of -ENOMEM)
Develop a better system for nonfatal error reporting than just piling on a bunch of assertions (look up assert best practices)
Rectify compiler warnings
Retool the FS tree return code system so it returns Windows error codes that are descriptive and can be passed back to the OS
when control returns to the Dokan callback; to do this, segregate the real return value (a win32 DWORD error code value) from
the int used internally to count things and ensure the call went successfully
Is MS's STL threadsafe? If not, we may have problems with the openFiles linked list being used in multiple threads in dokan_callbacks.cpp
but that can be overridden by having a mutex just for that purpose
Reimplement the openFiles array in dokan_callbacks.cpp as a multimap<BtrfsObjID, FileStruct> where FileStruct is a new struct that holds,
in addition to a FilePkg, the values passed as desiredAccess and shareMode to CreateFile; this should allow duplicates and properly
respect sharing and access mode requests from CreateFile
Remove type punning (casting void pointers back and forth) from parseFSTree; instead, possibly create an interface that each FSOP
implements, and each implementation class can have its own values that are passed with it
Add optimizations for FS tree parsing: use the rules of sorting within the tree to skip over parts entirely to get to the relevant item(s)
This is likely to be more feasible with smaller FSOPs, the likes of FSOP_NAME_TO_ID; although, for FSOP_DIR_LIST, it may be
highly effective to skip right to the INODE_ITEM for the parent directory and then resume parsing like usual
Be extra precise with filename strs due to overflow concerns: char foo[bar], strcpy, str conversions
Get rid of atoi!
Remove the chunk/root tree arrays and simply use CTOPs and RTOPs to get at their items
Add all function prototypes to header files (even intra-module ones)
Use the DIY-filter version of the FindFiles callback and do filtering as the dirlist FSOP happens so we don't create dirlist entries
that just get removed later by the post-hoc filtering process
When reading from mirrored chunks, alternate the stripe from which we read so as to boost performance (basically read striping)
Implement fully striped reading for RAID0/striped or RAID1/mirrored chunks for max performance
Use fprintf(stderr, ...) for error messages
Add a Ctrl+C handler to unmount and clean up gracefully
Decompress only the nodes of an extent that are going to be read in part or in whole; skip those that won't be read
Find better Windows error codes for failure conditions in Dokan callbacks
Be more consistent about whether error output is in the caller or the callee (currently they are both, somewhat randomly)
Look thru <WinError.h> and adjust Win32 error codes based on the message they will present to the user