profile

Metadata School

The Resource For August 2025

Published 15 days ago • 21 min read

Hello Reader, here is this month’s iRODS news and developments!

If you’re facing an issue with iRODS you’re not sure how to solve, please do drop me a line; if I’ve come across a solution or seen something relevant elsewhere, I’ll do my best to let you know. Or just drop me a mail to say ‘Hi’. Always nice to hear from people!

News

Breaking news - I have some very limited availability for consultancy.

My website is still in development, but if I was going to write this as a Thought-leadery LinkedIn post, it would go something like this;

iRODS Infrastructure Consulting Services

Leverage proven expertise to accelerate your iRODS deployment, minimize risks, and optimize performance at scale.

Deployment & Infrastructure • Automated Installation & Orchestration - Streamline deployments across bare metal, Docker, and Kubernetes environments with Infrastructure as Code approaches that reduce deployment time by 60-80% and eliminate configuration drift.

• Architecture Review & Optimization - Drawing from experience managing 40PB across 200+ servers, I provide actionable recommendations to improve performance, reduce costs, and prevent common pitfalls before they impact production

Migration & Upgrades • Low-Downtime Upgrade Strategy - Having successfully upgraded production systems from iRODS 3.3.1 to 4.3.3, I can develop tailored migration plans for your systems that minimize business disruption and eliminate upgrade-related outages

• Risk Assessment & Mitigation - Identify potential upgrade blockers early and create detailed rollback procedures to ensure business continuity throughout the transition

Operations & Reliability • DevSecOps Integration - Implement CI/CD pipelines and automated testing for iRODS configurations, reducing manual errors and accelerating deployment cycles

• Monitoring & Observability Framework - Establish comprehensive monitoring strategies focused on the CAP theorem (Consistency, Availability, Partition tolerance) with early warning systems that prevent outages before they occur

Value Delivered: Reduced operational overhead, improved system reliability, faster time-to-production, and measurable ROI through optimized resource utilization.

OK, pitch over, onto the news!

Mastodon Toots

GitHub Activity

Robot Warning; the following has been generated by Claude looking through the past 30 days of issues and generating summaries. I do read through them before posting, but in case anything slips through, or doesn't look right, do let me know.

Main Repository (irods/irods)

Open Issues – irods/irods

Performance Improvement for Rename/Move Operations in iRODS

Overview

A proposed enhancement to improve the performance of rename and move operations in iRODS by restructuring how physical path information is stored in the database.

Current Challenges

The existing database structure requires updating multiple entries during rename/move operations, which can be slow and destructive, especially for large collections.

Proposed Solution

Introduce a new database table r_phy_main to model physical path information as a tree-like structure:

  • Replace data_path with a new phy_id column
  • Create a new table with columns:
  • id: Unique identifier
  • pid: Parent ID
  • type: Path element type (file/directory)
  • path_element: Single path component

Potential Benefits

  • Significantly faster rename/move operations
  • Reduced database storage
  • Increased flexibility in path manipulation
  • Potential for O(1) update

​

Issue Summary:

A bug has been identified where recalculating physical quotas sometimes produces incorrect totals. The issue was discovered during work on the HTTP API’s quotas support and is reproducible using a provided shell script or via the HTTP API’s test_quotas_endpoint. The problem persists even with the connection pool disabled, suggesting that it should be replicable with icommands. Initial assumptions pointed to the connection pool as the culprit; however, further testing confirmed that the connection pool is not responsible. The issue is evident in scenarios where quick operations succession does not allow the database transactions to complete correctly, leading to erroneous quota reports, such as reporting quota_over: 24 instead of the expected quota_over: 22.

Comments Summary:

  • e issue might be linked to a previously reported problem, as suggested by a reference to issue #4089.
  • quiries were made about which specific operations in the shell script fail unexpectedly; it was clarified that while no operations fail outright, the final quota listing occasionally shows incorrect totals.
  • rther clarification was requested on the output considered incorrect or surprising, leading to an update in the issue description to better highlight the erroneous outcomes.

This problem has been observed in version tests against iRODS 4.3.4 and 5.0.1, and adding sleep calls within the HTTP API’s quota tests temporarily resolves the issue, indicating a timing or synchronization problem. The community is encouraged to investigate this further to identify a more permanent solution.

​

Issue Summary: The iRODS 2025 Roadmap includes plans to integrate certain stable plugins directly into the iRODS server. Among these, the Logical Quotas rule engine plugin (REP) is targeted for redesign and potential absorption. The proposed new design would model after the established physical quotas system, potentially using a new database table to manage quotas, thus eliminating the need for Policy Enforcement Points (PEPs) and possibly metadata. This change is motivated by the need to address inaccuracies and drift in quota totals currently experienced with the Logical Quotas REP, which also necessitates periodic recalibration via a recalculate-totals command. The redesign aims to simplify the integration process and enhance the reliability and performance of quota management within iRODS.

​

Summary of Issue:

The issue focuses on the documentation of access_time grid configuration options for the iadmin get_grid_configuration command. Currently, while these options are documented in the system overview, they are not listed in the help text for the command. The suggestion is to either add these options to the help text or remove the documented configuration options to maintain consistency.

Recommended Action:

Update the iadmin get_grid_configuration help text to include access_time grid configuration options in the 5.0.2 release, ensuring comprehensive and consistent documentation for users.

  • State: open Labels: testing Description: https://github.com/irods/irods/issues/8613; https://github.com/irods/irods/issues/8613 will instead be only for irsync.

​

Bug Report: istream Read Behavior with Non-Existent Replica

Issue Summary

A bug was identified in iRODS versions 4.3.4 and 5.0.1 where the istream read command does not report an error when attempting to read a replica from a resource that does not contain the data object.

Reproduction Steps

  1. Create two separate resources using iadmin mkresc
  2. Create a test file and put it on the first resource using iput -R resc1
  3. Attempt to read the file from the second resource using istream read -R
    resc2

Expected Behavior

The command should return an error message indicating that no replica exists on the specified resource, similar to the behavior of iget.

Actual Behavior

istream read silently returns the data from the existing replica on the first resource, with a zero exit status, without reporting any error.

Technical Context

This issue appears related to a similar problem previously documented for iget (referenced in GitHub issue #4475). The problem likely involves the DataObjOpen or replica_open API not properly handling replica accessibility checks.

Observations and Recommendations

  • The bug is reproducible across iRODS 5.x versions
  • A fix would require modifying the replica access validation in

​

Summary of Issue:

A critical inconsistency has been identified in how different iRODS clients handle malformed characters (such as null bytes, , and non-printable characters) during metadata operations across iRODS version 5.0.0/1.

Key Observations:

  • Different client implementations (PRC, gocmd, iCommands) exhibit varying behaviors when processing metadata with non-standard characters
  • iAssociateKeyValuePairsToObj can successfully add metadata with these characters
  • n-C++ clients like PRC and gocmd fail when attempting to query or list such metadata
  • iquest and ils can handle these characters by treating them as empty text

Specific Failure Modes:

  • Python PRC client: Raises XML parsing errors when attempting to query or list metadata
  • Go client (gocmd): Generates an “Unexpected error” with XML syntax error
  • iCommands: Successfully lists metadata with these characters

Potential Impact: This inconsistency could cause significant interoperability issues between different iRODS client implementations, potentially leading to metadata retrieval failures or data access problems.

Recommended Actions: 1. Standardize metadata character handling across all client implementations 2. Implement consistent error handling or character sanitization 3. Consider adding explicit validation for metadata attribute and value characters

​

Issue Summary:

A user reported a bug in iRODS 4.3.4 where the msiAssociateKeyValuePairsToObj() microservice consistently returns a CAT_INVALID_ARGUMENT error when attempting to attach metadata to data objects, collections, or users using Python Rule Engine Plugin (PREP).

Detailed Observations:

  • The issue occurs in multiple scenarios, including rule files and PEP calls
  • Consistent error codes include CAT_INVALID_ARGUMENT and RULE_ENGINE_ERROR
  • fferent test cases produced varying log outputs, including potential UTF-8 encoding issues

Test Scenarios and Results: 1. PEP calls consistently produce CAT_INVALID_ARGUMENT errors 2. Rule file tests showed varied behaviors:

  • Errors when attempting metadata attachment to collections
  • Potential UTF-8 byte sequence problems
  • Inconsistent error logging depending on specific script modifications

Community Discussion: The issue was initially suspected to be a duplicate of two previous GitHub issues (#8265 and #8528). After extensive testing, the reporter confirmed similarities but noted distinct behavioral differences across iRODS versions.

Recommended Next Steps:

A recent issue has been raised concerning the review of core.re in the context of determining which options might need to be considered as zone-wide rather than limited to narrower scopes. This initiative stems from ongoing developments related to implementing quotas in the iRODS HTTP API, which highlighted the potential need for better alignment of configuration options at a broader, zone- wide level.

The issue can be traced back to discussions in a pull request on the iRODS HTTP API GitHub repository, where the need for migrating specific options into the catalog was identified. This migration is crucial for supporting enhanced functionality and maintaining consistency across different parts of the iRODS ecosystem.

In the recent GitHub discussion, it was highlighted that there is a discrepancy in the GenQuery1 queries utilized for resource quotas in iRODS. Specifically, the issue points out that while one query condition checks QUOTA_RESC_ID !=
'0', another looks at QUOTA_RESC_NAME != '0'. The links provided in the issue direct to the relevant lines in the iRODS client icommands GitHub repository. The reporter suggests that both queries should uniformly use QUOTA_RESC_ID for consistency and to prevent potential confusion in the future.

​

An issue has been raised regarding the behavior of group quotas in iRODS when they are disabled and then re-enabled. The problem is that when a group quota is disabled after updates to data usage and then re-enabled, the quota’s calculated values are not reset but are retained. This behavior is not currently reflected in the iRODS documentation or the iadmin help text, leading to potential confusion for administrators.

The issue provides a detailed example using the iRODS command line (iadmin and istream commands), illustrating that disabling a group quota hides its information without erasing it from the catalog. This retained data is then still visible when the quota is re-enabled, showing no reset in quota calculations despite the quota having been disabled.

The community discussion is centered around whether this behavior should be merely documented or if the functionality itself should be adjusted. The concern is that while this might be an intended optimization, it could be unexpected and confusing for system administrators managing group quotas.

  • Documentation Proposal**: The issue suggests adding documentation to both the help text of iadmin and the iRODS official documentation site to clarify this behavior.
  • Behavioral Change Consideration**: Additionally, there’s an open question regarding whether the behavior itself should be altered — specifically, whether disabling and re-enabling a quota should reset its values to avoid confusion.

Feedback from the community and further discussions are encouraged to determine the best path forward, ensuring both clarity in documentation and intuitive system behavior.

A bug has been identified in the iRODS server where negative integers passed as replica numbers are silently ignored instead of triggering an error. This issue was discovered during HTTP API testing with iRODS server version 5.0.1.

The problem affects multiple stable branches:

  • main
  • 5-0-stable
  • 4-3-stable

The expected behavior is for the server to explicitly report an error when a negative integer is provided as a replica number, rather than silently processing the request.

Additional context and discussion can be found in a GitHub pull request comment at: https://github.com/irods/irods_client_http_api/pull/454#discussion_r2280126746

Recommended action: Implement input validation to ensure replica numbers are non-negative and return an appropriate error message when negative values are detected.

Proposed Enhancement for Error Handling in Server Resource Management

Current Behavior:

  • The server already returns an error when both a replica number and resource name are passed simultaneously
  • The proposed change would extend this error handling to scenarios involving resource hierarchy strings

Recommended Action:

  • Implement error checking across all relevant APIs
  • Be sure that when a resource hierarchy string is passed along with either a replica number or resource name, the server returns an appropriate error message

Branches to be Updated:

  • main
  • 5-0-stable
  • 4-3-stable

Implementation Scope:

  • Review and modify APIs that handle resource parameters
  • Add validation to prevent conflicting parameter combinations
  • Provide clear, consistent error messaging

Next Steps:

  • Develop test cases to verify the new error handling behavior
  • Update documentation to reflect the parameter validation changes

​

Summary of Issue and Comments

Issue Overview: A user reported a memory usage problem with iRODS iput/irsync commands when uploading large directories. Specifically, the issue occurs during recursive uploads of multiple files, causing the irodsAgent process to consume increasing amounts of memory until it crashes.

Key Details:

  • Environment: iRODS version 5.0.1 on AlmaLinux 9.6
  • Reproduction Steps:
  1. Create a directory with 1000 files (5MB each)
  2. Use iput -vPr or irsync -vr to upload recursively
  • Observed Behavior:
  • Memory usage of irodsAgent process continuously increases
  • Process crashes around 60 files on a 2GB memory container
  • Errors include “SYS_HEADER_READ_LEN_ERR” and connection endpoint failures

Potential Impact: The memory leak prevents successful large directory uploads and can cause data transfer interruptions.

Comment Response: A maintainer attempted to reproduce the issue on the main branch using a Docker container but could not replicate the memory problems. They suggested investigating potential local rule configurations that might be causing the unexpected behavior.

Recommended Next Steps: 1. Verify the issue on a clean, vanilla iRODS installation 2. Investigate potential custom rule or configuration interactions

Issue Summary

A user is experiencing authentication issues when attempting to initialize an iRODS connection with a password containing the “#” special character. The problem occurs specifically when using the iinit command, while other authentication methods like CyberDuck work without issue.

Environment Details

  • iRODS Version: 4.3.1
  • Operating System: Ubuntu 18.04.6 LTS

Observed Problem

When running iinit, the user receives an authentication error: “CAT_INVALID_USER: failed to perform request”. Server logs indicate an authentication plugin operation failure.

Verification Steps

  • User account exists and appears normal in iuserinfo
  • Password can be set successfully on the iCAT server
  • Alternative authentication methods (CyberDuck) function correctly

Recommended Actions

  1. Investigate potential character escaping or encoding issues with special characters in iRODS authentication
  2. Check iRODS authentication plugin compatibility with special characters
  3. Verify client-side authentication mechanism for command-line tools

Next Steps

Users experiencing similar issues should:

  • Confirm the exact authentication method
  • Verify password complexity and special character handling
  • Test alternative authentication mechanisms

​

  • [iadmin moduser type failing in some circumstances.](https://github.com/irods/irods/issues/8607)

Issue Summary:

A user encountered difficulties using the iadmin moduser command to change user types in iRODS 4.3.1 on Ubuntu 18.04. Specifically:

  • Attempts to change users with a custom ds-service type to rodsuser failed
  • Changing a user to rodsadmin worked, but reverting back to rodsuser failed
  • Errors included SYS_LIBRARY_ERROR and CAT_INVALID_USER_TYPE

The failures appeared to be related to inconsistent JSON structure in the zone configuration, specifically in the zones.servers section where some entries are arrays and others are objects.

Comments Summary:

Developers identified the issue as likely stemming from an incorrect usage of the nlohmann::json library in the GeneralAdmin API. The root cause appears to be:

  • helper function checks for user type changes, potentially throwing an exception
  • The tedgin user change to rodsadmin worked because privilege level upgrade checks were bypassed
  • The zone configuration’s mixed array/object structure may be causing JSON parsing problems

A sanitized zone configuration file was provided to help diagnose the issue. The recommendation is to investigate the JSON structure and how it’s being parsed in the user type modification process.

Related GitHub issue #8233 about

Issue Summary:

A bug has been identified in iRODS versions 4.2.12 and 4.3.4 involving concurrent replication of data objects, particularly when file or collection names contain single quotes. The issue manifests as failed replication attempts with internal system errors (SYS_INTERNAL_ERR, error code -154000).

Key Observations:

  • Occurs during parallel replication of multiple data objects
  • nsistently reproducible when single quotes are present in file or collection names
  • Not observed in iRODS 5.0.1
  • Affects both collection and object names with single quotes
  • proximately 407 errors occurred during a batch of 151,000 object replications

Reproduction Steps: 1. Create test files with single quotes in names 2. Attempt parallel replication using multiple threads or background processes 3. Observe replication failures with specific error messages

Potential Root Cause: The issue appears related to GenQuery1 implementation and potential race conditions in the replica access table during concurrent operations.

Recommended Actions:

  • Avoid concurrent replication of objects with single quotes in names
  • Wait for potential fix in upcoming iRODS 4.3.5 release
  • Test replication in sequential mode if single-quoted paths are unavoidable

​

In the referenced GitHub issue, there is a call to revisit the implementation of the mysql_functions.sql in the iRODS project. Currently, the script uses command-line client binaries for MySQL/MariaDB instead of interfacing directly via pyodbc. The script features a stored procedure requiring a change in SQL delimiter, which ODBC does not traditionally support, hence the reliance on CLI. The suggestion is made to modify mysql_functions.sql by adjusting delimiters and newlines to make it compatible with pyodbc. This change would remove the dependency on the MySQL/MariaDB client binaries and address compatibility issues with certain versions of the MySQL ODBC connector (versions 8.0.40 through 8.3.0 and possibly beyond).

Commentary on the issue provides historical context and explores the reasons behind the initial design decisions. One comment inquires about the rationale for the existing abstraction and its presence in legacy iRODS repositories. Another comment notes that MySQL’s lack of native sequence support led to the emulation of sequences via tables and stored procedures. A lack of comprehensive documentation on creating stored procedures with compound statements through ODBC is speculated to be a reason for the original reliance on CLI tools instead of pyodbc. There is also a mention of having used pypyodbc as an intermediary solution. The discussions highlight a general uncertainty and a need for documentation regarding the use of ODBC for complex SQL operations within iRODS.

Summary of Issue:

The issue discusses an unnecessary CMake preprocessing step for the mysql_functions.sql file in the iRODS database plugin. Currently, the project uses configure_file to generate mysql_functions.sql from mysql_functions.sql.in, but the template contains no CMake variable references, resulting in an identical output file.

The recommendation is to remove this redundant preprocessing step, as it serves no functional purpose in the current version of the software.

Discussion Context:

The comments reveal historical context for the preprocessing step. It was previously necessary for compatibility with MySQL versions prior to 5.5, where some variable substitutions were likely required. However, in the current software version, this preprocessing is no longer needed.

A specific commit reference was shared demonstrating the previous need for variable substitution, confirming that the preprocessing was once meaningful but is now superfluous.

Recommended Action:

  • Remove the configure_file call for mysql_functions.sql.in
  • Directly use the original template file
  • Verify no loss of functionality after removing the preprocessing step

​

The proposed enhancement involves extending the HTTP API’s procApiRequest functionality to allow more flexible specification of packing instructions during serialization. This would enable callers to provide custom packing instruction tables, which would require corresponding support for deserialization in the iRODS server.

The enhancement aims to improve the flexibility of data serialization in the iRODS HTTP API, potentially allowing more customized data handling and transmission. The implementation would involve modifying the current API request processing to support dynamic packing instruction configuration.

A reference to a specific GitHub pull request discussion (https://github.com/irods/irods_client_http_api/pull/432#discussion_r2229679214) is provided for additional context about the proposed changes.

Closed Issues – irods/irods

Python iRODS Client (irods/python-irodsclient)

Open Issues – irods/python-irodsclient

Summary of Issue:

A user encountered an issue while trying to install the Python iRODS client on Ubuntu 24, facing a system-wide package management restriction (PEP 668) that prevents direct pip installation. Upon attempting to use the apt-installed version of python3-irodsclient, they discovered the package is significantly outdated (version 0.8.1 from 2018). The user seeks guidance on either updating the apt package version or removing the old version.

Key Technical Details:

  • Ubuntu 24 enforces externally managed Python environments
  • Recommended solutions include:
  1. Using virtual environments
  2. Installing via apt-get
  3. Using pipx for package management

Summary of Comments:

The project maintainers responded that they:

  • Do not manage the Ubuntu distribution package
  • Only publish packages to PyPI for pip installation
  • ggested the user contact Ubuntu package maintainers to request a version update

Recommended Actions: 1. Create a Python virtual environment 2. Contact Ubuntu package maintainers about updating the package version 3. Consider using pipx for easier Python package management

Potential Workarounds:

  • Use python3 -m venv to create an isolated environment
  • Install the latest version directly from PyPI within a virtual environment
  • Use pipx for application-specific package installations

​

Issue Summary:

A bug was discovered in the user creation process where attempting to create a local zone user with the same name as an existing remote user causes a MultipleResultsFound error. The proposed solution involves modifying the userManager.get() method to expand the user zone to the full local zone name when no zone is explicitly specified.

Potential Impact:

  • Affects user creation methods, including create() and create_with_password()
  • Prevents creating local users with names that match existing remote users

Technical Details:

  • Error occurs during user creation when zone is not explicitly defined
  • Recommended fix: Ensure all iRODS calls include complete user zone information

Resolution Status: The issue has been addressed and the fix was incorporated into a related pull request (#760). The development team plans to conduct further testing to validate the solution.

Discussion Highlights: The team acknowledged the bug and agreed on the proposed approach to resolve the user creation zone-matching problem. Consensus was reached quickly, with developers confirming the proposed solution and its implementation.

Next Steps:

  • Complete testing of the implemented fix
  • Verify resolution across different user creation scenarios

​

​

Issue Summary:

A bug has been identified in the GeneralAdminRequest API for removing remote users. When removing a user from a non-local zone, the home collection is only successfully deleted when the user is specified in the “user#zone” format. If the user and zone are passed as separate parameters, the home collection remains in the catalog.

Reproduction Steps: 1. Create a remote zone 2. Create a user in the remote zone 3. Attempt to remove the user using different parameter formats 4. Verify home collection removal

The issue demonstrates two scenarios:

  • th GENADM_REMOVE_USER_FMT=’combined’: Home and trash collections are successfully removed
  • With GENADM_REMOVE_USER_FMT=’’: Home and trash collections are not removed

Technical Impact: This bug affects the complete removal of remote users, potentially leaving orphaned collections in the iRODS catalog when using the GeneralAdmin API.

Recommended Action: Modify the GeneralAdmin API to consistently handle user removal across different parameter passing formats, ensuring home and trash collections are always removed when a user is deleted.

Environment:

  • Python iRODS Client (PRC)
  • iRODS system with remote zone functionality

​

​

A potential improvement has been proposed for the Python iRODS Client library regarding query behavior. The suggestion is to raise an error when attempting to execute a GenQuery without specifying any columns to return.

The rationale is that such a query carries no meaningful purpose, as no rows could or should be returned. By implementing an error, the library would prevent potentially confusing or unintended query executions and provide clearer guidance to developers about proper query construction.

This suggestion was originally raised by @korydraughn, indicating a focus on improving the library’s robustness and usability.

In the group admin interface of iRODS, there is an issue where the user_zone parameter is being ignored when using the UserAdminRequest endpoint. Attempts to use the zone parameter result in a CAT_SQL_ERR, as detailed in a related GitHub issue (https://github.com/irods/irods/issues/8583).

The comments on the issue provide further insights:

  • Initially, it was assumed that this behavior was by design, suggesting that the function users.create_with_password was not intended to handle the creation of remote users.
  • However, this assumption was quickly retracted when a commenter mentioned successfully adding a remote user using the igroupadmin mkuser
    user@otherzone     command.
  • Additionally, a link to a work-in-progress fix for this issue was shared, which can be found at https://github.com/irods/python-irodsclient/pull/760. This indicates ongoing efforts to address the problem directly in the client library.

​

Closed Issues – irods/python-irodsclient

​

externals (irods/externals)

Open Issues – irods/externals

Closed Issues – irods/externals

YODA (UtrechtUniversity/yoda)

Open Issues – UtrechtUniversity/yoda

Feature Request: Multiple Schema Support in Public Metadata Editor

Problem Statement: The current public metadata editor for the Yoda project only displays the latest default schema (version 3), despite multiple schemas being available within the Yoda system. Researchers and users need more flexibility in selecting and using different metadata schemas.

Proposed Solution: Implement a dropdown selection box that allows users to choose from available schemas, which would then load the selected schema in the public editor for metadata completion.

Motivation: While Yoda is an excellent metadata tool, it isn’t universally available across all organizations. Existing alternatives like CodeMeta and Dublin Core generators lack the user-friendly interface of the Yoda public editor.

Acceptance Criteria:

  • Add a schema selection mechanism to the public metadata editor
  • Enable users to choose from multiple available schemas
  • Dynamically load the selected schema for metadata input

Key Considerations:

  • Enhance usability for researchers with varying metadata requirements
  • Provide a more flexible metadata capture experience
  • Maintain the current intuitive design of the public editor

Next Steps:

  • Evaluate technical implementation of schema selection
  • Design user interface for schema dropdown
  • Test compatibility with existing metadata schema structures

The feature would significantly improve the metadata collection process by offering greater schema flexibility and user choice.

​

If you think someone else would appreciate this newsletter, they can sign up at https://theresource.metadata.school/​

Seven (!) Yaks were shaved in the making of this newsletter. That's what I get for asking A.I. to help.

113 Cherry St #92768, Seattle, WA 98104-2205
​Unsubscribe · Preferences​

Metadata School

Read more from Metadata School

Your monthly iRODS developments The Resource Hello Reader, here is this month’s iRODS news and developments! If you’re facing an issue with iRODS you’re not sure how to solve, please do drop me a line; if I’ve come across a solution or seen something relevant elsewhere, I’ll do my best to let you know. Or just drop me a mail to say ‘Hi’. Always nice to hear from people! The UGM last month meant I didn't have as much time to work on The Resource as normal, and I had missed that the automation...

2 months ago • 22 min read

Your monthly iRODS developments The Resource Hello Reader, here is this month’s iRODS news and developments! If you’re facing an issue with iRODS you’re not sure how to solve, please do drop me a line; if I’ve come across a solution or seen something relevant elsewhere, I’ll do my best to let you know. Or just drop me a mail to say ‘Hi’. Always nice to hear from people! News Did you miss me? Its been a while since the last newsletter, but I’m back with a bumper edition of iRODS news and...

4 months ago • 37 min read
snakes in 2025

Your monthly iRODS developments The Resource Image showing text with 'welcome to 2025' and snakes Hi everybody! Like many other newsletters or companies you might have forgotten you had subscribed to, The Resource wishes you a Happy New Year and much successful data management in 2025! Yes, before you ask, the fact you're getting this at all means that the newsletter, which has been on hiatus, whilst, amongst other things, I moved house. Now that that's over with, I'm looking to resurrect the...

8 months ago • 1 min read