Skip to content

Commit de27ea4

Browse files
committed
Merge remote-tracking branch 'upstream/release/v2.4.9.0' into store-hash
# Conflicts: # src/utils/ltfs_ordered_copy
2 parents e989d9b + 56baaf9 commit de27ea4

31 files changed

Lines changed: 826 additions & 279 deletions

.github/CONTRIBUTING.md

Lines changed: 75 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@ We love pull requests from everyone.
44

55
When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.
66

7-
Please note we have a [coding style guide](/docs/CODE_OF_CONDUCT.md), please follow it in all your interactions with the project.
7+
Please note we have a [coding style guide](../docs/CODING_STYLE.md), please follow it in all your interactions with the project.
88

99
1. Fork, then clone the repo
1010

@@ -25,5 +25,78 @@ Please note we have a [coding style guide](/docs/CODE_OF_CONDUCT.md), please fol
2525

2626
__Some things that will increase the chance that your pull request is accepted__
2727

28-
* Follow our [coding style guide](/docs/CODE_OF_CONDUCT.md).
28+
* Follow our [coding style guide](../docs/CODING_STYLE.md).
2929
* Write a good commit message.
30+
31+
# Branch Naming Conventions
32+
The structure and design conventions are based mainly on the “Conventional Branch” concept and the team’s current work process.
33+
34+
Note: These conventions are recommendations intended to improve readability and consistency of commits within pull requests and are not strictly enforced. Only the release and main branches are required to fully adhere to this naming convention.
35+
36+
## Purpose
37+
1. Purpose-driven Branch Names: Each branch name clearly indicates its purpose, making it easy for all developers to understand what the branch is for.
38+
2. Integration with CI/CD: By using consistent branch names, it can help automated systems (like Continuous Integration/Continuous Deployment pipelines) to trigger specific actions based on the branch type.
39+
3. Better type and version control: Branches are related to a specific type of change in the code and the version that is being worked on, allowing for a much better backtracking.
40+
41+
## Basic Rules
42+
- Naming structure:
43+
`<type>/<description>`
44+
- Naming prefixes (Types):
45+
- feature/: For new features (e.g., feature/add-login-page).
46+
- fix/: For general fixes or code correcting.
47+
- update/: For code upgrade or non-breaking code refactoring.
48+
- chore/: For non-code tasks like dependency, docs updates (e.g., chore/update-dependencies).
49+
- release/: For branches preparing a release (e.g., release/v1.2.0).
50+
- Use Lowercase Alphanumeric and Hyphens: Always use lowercase letters (a-z), numbers (0-9), and hyphens to separate words. Avoid special characters, underscores, or spaces.
51+
- No Consecutive or Trailing Hyphens: Ensure that hyphens are used singly, with no consecutive hyphens (feature/new--login) or at the end (feature/new-login-).
52+
- Keep It Clear and Concise: The branch name should be descriptive yet concise, clearly indicating the purpose of the work.
53+
- Include Ticket Numbers: If applicable, include the ticket number from your project management tool to make tracking easier. For example, for a ticket issue-123, the branch name could be feature/issue-123-new-login.
54+
55+
## General Project Structure
56+
```
57+
main
58+
├── release/v1.x.x
59+
│ ├── feature/lorem-ipsum
60+
│ └── fix/ipsum-dolor
61+
├── release/v2.x.x
62+
│ └── chore/dolor-sit
63+
└── release/v3.x.x
64+
├── update/sit-amet
65+
├── feature/amet-consectetur
66+
└── chore/consectetur-adipiscing
67+
```
68+
- main: This branch should only contain working versions completely tested and only receive pull requests from finalized release branches. All new release/ branches must come from this one.
69+
- release: The creation of these branches should be done from the last version of main when created. Only this branches can make pull requests to main.
70+
- Other branches: All working branches should come from a release branch. These are the only ones that should receive direct commits from changes made by development staff. These branches should only do PR to the active release branch.
71+
72+
# Commits Naming Conventions
73+
The structure and design conventions are based mainly on the “Conventional Branch” concept and the team’s current work process.
74+
75+
## Purpose
76+
1. Automatically generating CHANGELOGs: When the commits are concise, and precise changelogs can be automated or semi-automated from the commit history.
77+
2. Communicating the nature of changes to everyone: Being able to understand the type of changing by just looking at a name and understanding the basics of a commit just by the title is useful in analysis and backtrack situations.
78+
3. Building code habits and good practices: Maintaining structured commits also leads to more precise coding practices and coherent code changes.
79+
80+
## Basic Rules
81+
- Naming structure:
82+
```
83+
<type>: <description>
84+
85+
[optional body]
86+
```
87+
- Naming prefixes (Types):
88+
- fix: A commit of the type fix patches a bug in your codebase.
89+
- feat: A commit of the type feat introduces a new feature to the codebase
90+
- <type>!: A commit that appends a ! after the type introduces a breaking change. A breaking change can be part of commits of any type.
91+
- update: A commit of type update changes existing code or refactors functions without changing functionality of adding features in your codebase.
92+
- build: A commit of type build changes build process in your codebase.
93+
- docs: A commit of type docs is for creation or updating documentation in your codebase.
94+
- chore: A commit of type chore is for every other minor task in your codebase.
95+
- Commits must be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the optional !, and required terminal colon and space.
96+
- A description must immediately follow the colon and space after the type prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
97+
- A longer commit body may be provided after the short description, providing additional contextual information about the code changes. The body must begin one blank line after the description.
98+
- A commit body is free-form and may consist of any number of newline separated paragraphs.
99+
100+
# Bibliography
101+
[1] “Conventional Branch,” Conventional Branch, 2025. https://conventional-branch.github.io/ (accessed 2025).</br>
102+
[2] “Conventional Commits,” Conventional Commits. https://www.conventionalcommits.org/en/v1.0.0/ (accessed 2025).

README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -178,6 +178,7 @@ One thing you need to pay attention to here is, that the unmount command continu
178178
The [`ltfs_ordered_copy`](https://github.com/LinearTapeFileSystem/ltfs/wiki/ltfs_ordered_copy) is a program to copy files from source to destination with LTFS order optimization.
179179

180180
It is written in python and it can work with both python2 and python3 (Python 2.7 or later is strongly recommended). You need to install the `pyxattr` module for both python2 and python3.
181+
For nicer-looking progress bars while copying, it is also recommended you install `tqdm`.
181182

182183
# Building the LTFS from this GitHub project
183184

configure.ac

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -36,7 +36,7 @@
3636
dnl
3737
dnl LTFS configure.ac.
3838
dnl
39-
AC_INIT([LTFS], [2.4.5.1 (Prelim)], IBM corporation.)
39+
AC_INIT([LTFS], [2.4.8.4 (Prelim)], IBM corporation.)
4040
AC_CONFIG_SRCDIR([src/main.c])
4141
AC_CONFIG_AUX_DIR([build-aux])
4242
AC_CONFIG_MACRO_DIRS([m4])
@@ -49,7 +49,10 @@ AC_USE_SYSTEM_EXTENSIONS
4949
AC_PROG_CC_C99
5050
AM_PROG_CC_C_O
5151
AM_PROG_AR
52-
AC_PROG_LIBTOOL
52+
dnl
53+
dnl Initialize libtool - use LT_INIT for libtool 2.x, AC_PROG_LIBTOOL for 1.x
54+
dnl
55+
m4_ifdef([LT_INIT], [LT_INIT], [AC_PROG_LIBTOOL])
5356

5457
dnl
5558
dnl Detecting OS
@@ -374,7 +377,7 @@ if test "x${snmp}" != "xno"
374377
then
375378
SNMP_ENABLE="-D ENABLE_SNMP"
376379
SNMP_MODULE_CFLAGS="`net-snmp-config --cflags 2> /dev/null`";
377-
SNMP_MODULE_LIBS_A="`net-snmp-config --agent-libs` 2> /dev/null";
380+
SNMP_MODULE_LIBS_A="`net-snmp-config --agent-libs 2> /dev/null`";
378381
SNMP_MODULE_LIBS="`net-snmp-config --libs 2> /dev/null`";
379382
if test -z "$SNMP_MODULE_LIBS_A"
380383
then

docs/CODE_OF_CONDUCT.md

Lines changed: 79 additions & 122 deletions
Original file line numberDiff line numberDiff line change
@@ -1,133 +1,90 @@
1-
Coding Style guide for LTFS
2-
=============
1+
# Code of Conduct
32

4-
Naming conventions
5-
-------------
3+
## Our Pledge
64

7-
- We don't use capital letters, except on defines and enumerators (see below).
8-
- Public APIs are always prefixed by the name of that module:
9-
* ltfs.c: ltfs_statfs(), ltfs_open(), ltfs_close(), ltfs_read()
10-
* fs.c: fs_resolve_dentry(), fs_set_name(), fs_set_creation_time()
5+
We pledge to make our community welcoming, safe, and equitable for all.
116

7+
We are committed to fostering an environment that respects and promotes the dignity, rights, and contributions of all individuals, regardless of characteristics including race, ethnicity, caste, color, age, physical characteristics, neurodiversity, disability, sex or gender, gender identity or expression, sexual orientation, language, philosophy or religion, national or social origin, socio-economic position, level of education, or other status. The same privileges of participation are extended to everyone who participates in good faith and in accordance with this Covenant.
128

13-
Spaces, tabs and commas
14-
-------------
9+
## Encouraged Behaviors
1510

16-
When indenting the code, always use TABs with 4 spaces. Do not replace TABs by spaces. Remove trailing spaces of a line and empty lines at the end of file.
11+
While acknowledging differences in social norms, we all strive to meet our community's expectations for positive behavior. We also understand that our words and actions may be interpreted differently than we intend based on culture, background, or native language.
1712

18-
When writing arguments to a function or defining enums, also use the following comma conventions:
13+
With these considerations in mind, we agree to behave mindfully toward each other and act in ways that center our shared values, including:
1914

15+
1. Respecting the **purpose of our community**, our activities, and our ways of gathering.
16+
2. Engaging **kindly and honestly** with others.
17+
3. Respecting **different viewpoints** and experiences.
18+
4. **Taking responsibility** for our actions and contributions.
19+
5. Gracefully giving and accepting **constructive feedback**.
20+
6. Committing to **repairing harm** when it occurs.
21+
7. Behaving in other ways that promote and sustain the **well-being of our community**.
2022

21-
```
22-
call_function(arg1, arg2, arg3);
2323

24-
call_another_function(
25-
very_long_argument1,
26-
very_long_argument2,
27-
very_long_argument3
28-
);
29-
30-
enum very_cool_enumerator {
31-
VERY_COOL_1,
32-
VERY_COOL_2,
33-
VERY_COOL_3,
34-
};
35-
```
36-
37-
Macros and defines
38-
-------------
39-
40-
When defining wrappers around functions using macros do that using lowercase characters. Defines always go in uppercase.
41-
42-
```
43-
#define wrapper_around_some_function(x,y) \
44-
...
45-
46-
#define LTFS_MAX_VALUE 2112
47-
```
48-
49-
Functions
50-
-------------
51-
52-
Return type, function name and its parameters should go all in a single line, except if the parameters are too long.
53-
54-
55-
```
56-
void ltfs_function(void *params)
57-
{
58-
}
59-
60-
void ltfs_function_with_many_parameters(void *params1,
61-
void *params2, void *params3)
62-
{
63-
}
64-
```
65-
66-
Conditional tests
67-
-------------
68-
69-
```
70-
if (condition) {
71-
line 1;
72-
line 2;
73-
} else
74-
line 3;
75-
76-
if (another condition)
77-
do this;
78-
else
79-
do that;
80-
81-
if (yet another condition) {
82-
/*
83-
* It's ok to open brackets when adding comments,
84-
* just to make it clear where the scope ends.
85-
* That can improve readability when comments
86-
* span across multiple lines.
87-
*/
88-
do something else;
89-
}
90-
```
91-
92-
Loops
93-
-------------
94-
95-
```
96-
for (x=start; x<end; ++x) {
97-
body
98-
}
99-
```
100-
101-
Comments
102-
-------------
24+
## Restricted Behaviors
10325

104-
Please do not use C++ style comments (//), except when
105-
temporarily commenting out a line of code. If too many
106-
lines are being commented out consider using #if 0 instead
107-
or, preferably, just remove that code completely.
108-
109-
For comments, always use the C style (/* comments */),
110-
even if that's just a single line.
26+
We agree to restrict the following behaviors in our community. Instances, threats, and promotion of these behaviors are violations of this Code of Conduct.
27+
28+
1. **Harassment.** Violating explicitly expressed boundaries or engaging in unnecessary personal attention after any clear request to stop.
29+
2. **Character attacks.** Making insulting, demeaning, or pejorative comments directed at a community member or group of people.
30+
3. **Stereotyping or discrimination.** Characterizing anyone’s personality or behavior on the basis of immutable identities or traits.
31+
4. **Sexualization.** Behaving in a way that would generally be considered inappropriately intimate in the context or purpose of the community.
32+
5. **Violating confidentiality**. Sharing or acting on someone's personal or private information without their permission.
33+
6. **Endangerment.** Causing, encouraging, or threatening violence or other harm toward any person or group.
34+
7. Behaving in other ways that **threaten the well-being** of our community.
35+
36+
### Other Restrictions
37+
38+
1. **Misleading identity.** Impersonating someone else for any reason, or pretending to be someone else to evade enforcement actions.
39+
2. **Failing to credit sources.** Not properly crediting the sources of content you contribute.
40+
3. **Promotional materials**. Sharing marketing or other commercial content in a way that is outside the norms of the community.
41+
4. **Irresponsible communication.** Failing to responsibly present content which includes, links or describes any other restricted behaviors.
42+
43+
44+
## Reporting an Issue
45+
46+
Tensions can occur between community members even when they are trying their best to collaborate. Not every conflict represents a code of conduct violation, and this Code of Conduct reinforces encouraged behaviors and norms that can help avoid conflicts and minimize harm.
47+
48+
When an incident does occur, it is important to report it promptly. To report a possible violation, **communicate with @jjashgar or @chukero**
49+
50+
Community Moderators take reports of violations seriously and will make every effort to respond in a timely manner. They will investigate all reports of code of conduct violations, reviewing messages, logs, and recordings, or interviewing witnesses and other participants. Community Moderators will keep investigation and enforcement actions as transparent as possible while prioritizing safety and confidentiality. In order to honor these values, enforcement actions are carried out in private with the involved parties, but communicating to the whole community may be part of a mutually agreed upon resolution.
51+
52+
53+
## Addressing and Repairing Harm
54+
55+
56+
If an investigation by the Community Moderators finds that this Code of Conduct has been violated, the following enforcement ladder may be used to determine how best to repair harm, based on the incident's impact on the individuals involved and the community as a whole. Depending on the severity of a violation, lower rungs on the ladder may be skipped.
57+
58+
1) Warning
59+
1) Event: A violation involving a single incident or series of incidents.
60+
2) Consequence: A private, written warning from the Community Moderators.
61+
3) Repair: Examples of repair include a private written apology, acknowledgement of responsibility, and seeking clarification on expectations.
62+
2) Temporarily Limited Activities
63+
1) Event: A repeated incidence of a violation that previously resulted in a warning, or the first incidence of a more serious violation.
64+
2) Consequence: A private, written warning with a time-limited cooldown period designed to underscore the seriousness of the situation and give the community members involved time to process the incident. The cooldown period may be limited to particular communication channels or interactions with particular community members.
65+
3) Repair: Examples of repair may include making an apology, using the cooldown period to reflect on actions and impact, and being thoughtful about re-entering community spaces after the period is over.
66+
3) Temporary Suspension
67+
1) Event: A pattern of repeated violation which the Community Moderators have tried to address with warnings, or a single serious violation.
68+
2) Consequence: A private written warning with conditions for return from suspension. In general, temporary suspensions give the person being suspended time to reflect upon their behavior and possible corrective actions.
69+
3) Repair: Examples of repair include respecting the spirit of the suspension, meeting the specified conditions for return, and being thoughtful about how to reintegrate with the community when the suspension is lifted.
70+
4) Permanent Ban
71+
1) Event: A pattern of repeated code of conduct violations that other steps on the ladder have failed to resolve, or a violation so serious that the Community Moderators determine there is no way to keep the community safe with this person as a member.
72+
2) Consequence: Access to all community spaces, tools, and communication channels is removed. In general, permanent bans should be rarely used, should have strong reasoning behind them, and should only be resorted to if working through other remedies has failed to change the behavior.
73+
3) Repair: There is no possible repair in cases of this severity.
74+
75+
This enforcement ladder is intended as a guideline. It does not limit the ability of Community Managers to use their discretion and judgment, in keeping with the best interests of our community.
76+
77+
78+
## Scope
79+
80+
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public or other spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
81+
82+
83+
## Attribution
84+
85+
This Code of Conduct is adapted from the Contributor Covenant, version 3.0, permanently available at [https://www.contributor-covenant.org/version/3/0/](https://www.contributor-covenant.org/version/3/0/).
86+
87+
Contributor Covenant is stewarded by the Organization for Ethical Source and licensed under CC BY-SA 4.0. To view a copy of this license, visit [https://creativecommons.org/licenses/by-sa/4.0/](https://creativecommons.org/licenses/by-sa/4.0/)
88+
89+
For answers to common questions about Contributor Covenant, see the FAQ at [https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq). Translations are provided at [https://www.contributor-covenant.org/translations](https://www.contributor-covenant.org/translations). Additional enforcement and community guideline resources can be found at [https://www.contributor-covenant.org/resources](https://www.contributor-covenant.org/resources). The enforcement ladder was inspired by the work of [Mozilla’s code of conduct team](https://github.com/mozilla/inclusion).
11190

112-
For documenting functions, please use the Doxygen-friendly
113-
format below:
114-
115-
```
116-
/**
117-
* General comments about the function go here.
118-
* @param var1 Describe what var1 does.
119-
* @param var2 Describe what var2 does.
120-
* @return Describe what's expected to be returned both on
121-
* success and on error situation. Also, note that we
122-
* tabulate with one extra space when the comments span
123-
* multiple lines.
124-
*/
125-
int function(void *var1, void *var2)
126-
{
127-
}
128-
```
129-
130-
Maximum line length
131-
-------------
132-
133-
Lines must not exceed 100 characters.

0 commit comments

Comments
 (0)