You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.MD
+108-9Lines changed: 108 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,6 @@
1
1
# Contributing to AnalyzeMFT
2
2
3
-
We welcome all contributions to AnalyzeMFT and appreciate your effort in helping improve this project!
4
-
5
-
Please take a moment to read through the following guidelines before opening an issue, pull request (PR), or making any contributions.
3
+
We welcome all contributions to AnalyzeMFT and appreciate your effort in helping improve this project! Please take a moment to read through the following guidelines before opening an issue, pull request (PR), or making any contributions.
6
4
7
5
## Code of Conduct
8
6
@@ -13,31 +11,132 @@ Please take a moment to read through the following guidelines before opening an
13
11
To maintain a clean and manageable project history:
14
12
- Each commit should represent **ONE** discrete change. Avoid bundling multiple changes into a single commit.
15
13
- PRs will be **squashed** if necessary, but we strongly prefer a clear change-by-change commit history. This is essential for effective debugging and maintaining code quality.
16
-
14
+
17
15
## How to Contribute
18
16
19
17
### Reporting Bugs
18
+
20
19
-**Create an issue** for any bug you encounter. Make sure to describe the issue clearly and include any necessary information (e.g., error messages, logs, steps to reproduce).
21
20
- Feel free to contribute a fix after reporting!
22
21
23
22
### Proposing New Features
24
-
-**Open an issue** to discuss your proposed feature before opening a PR. It’s important to make sure it aligns with the project goals.
23
+
24
+
-**Open an issue** to discuss your proposed feature before opening a PR. It's important to make sure it aligns with the project goals.
25
25
26
26
### Making Changes
27
+
27
28
1.**Fork the repository** and create your branch from `main`.
28
29
2.**Make your changes**, ensuring that they address one issue at a time.
29
30
3.**Test your changes** thoroughly.
30
31
4.**Submit a pull request**, referencing the related issue if applicable.
31
32
32
33
### Commit Messages
34
+
33
35
- Use concise and descriptive commit messages that explain the context of your change.
34
36
- Reference the issue number (if applicable) in your commit message.
35
37
38
+
Example:
39
+
```
40
+
Fix parsing of reparse point attribute (#123)
41
+
42
+
Add error handling for incomplete reparse point data
43
+
Update documentation for reparse point parsing
44
+
```
45
+
36
46
## Code Style
37
47
38
-
- Ensure your code follows the coding style used in the project.
39
-
- Code quality is a priority, so be sure to run any existing linting or formatting checks before submitting your PR.
48
+
We follow a specific code style to maintain consistency throughout the project. Please adhere to the following guidelines:
49
+
50
+
### Python Code Style
51
+
52
+
1. Use 4 spaces for indentation (no tabs).
53
+
2. Follow PEP 8 guidelines for naming conventions and code layout.
54
+
3. Use type hints for function parameters and return values.
offset (int): The starting offset of the attribute.
92
+
raw_data (bytes): The raw MFT record data.
93
+
94
+
Returns:
95
+
Dict[str, Any]: A dictionary containing the parsed attribute information.
96
+
"""
97
+
```
98
+
99
+
### SQL - work in progress
100
+
101
+
We're working on bringing an SQL engine into this program because (IMO) it's the better way to sort and analyze massive datasets. With that in mind, I'd like to lay out a few SQL specific items:
102
+
103
+
SQL keywords need to be uppercase.
104
+
SQL data columns should be lowercase and use `_` to separate words.
105
+
106
+
```
107
+
CREATE TABLE mft_record (
108
+
id INTEGER PRIMARY KEY,
109
+
record_number INTEGER NOT NULL,
110
+
parent_record_number INTEGER
111
+
)
112
+
```
113
+
114
+
### Pull Requests
115
+
116
+
After undering the joy of learning why branches have locks and the issues with trusting people to test fully, we're going to revamp the PR process.
117
+
118
+
1. Instituted branch safety on the main branch
119
+
2. Built out a test suite (if anyone knows how to make this work on GH, lmk)
120
+
121
+
PRs will now be required to fit this format:
122
+
123
+
```
124
+
## Description
125
+
This PR adds support for parsing reparse point attributes in MFT records. It includes:
126
+
- New function `parse_reparse_point` in `mft_record.py`
127
+
- Updated `MftRecord` class to handle reparse point attributes
128
+
- New tests for reparse point parsing in `test_mft_record.py`
129
+
- Updated documentation in README.md
130
+
131
+
Fixes #123
132
+
133
+
## Checklist
134
+
- [x] Code follows the project's style guidelines
135
+
- [x] Tests have been added/updated
136
+
- [x] Documentation has been updated
137
+
- [x] All tests pass locally
138
+
```
40
139
41
-
## Thank You
140
+
# Thank You
141
+
#### Your contribution is greatly appreciated, and we look forward to reviewing your work!
42
142
43
-
Your contribution is greatly appreciated, and we look forward to reviewing your work!
0 commit comments