irods / irods_client_globus_connector

The iRODS Globus Connector

The Integrated Rule-Oriented Data System (iRODS) is open source data management software used by research, commercial, and governmental organizations worldwide.

iRODS is released as a production-level distribution aimed at deployment in mission critical environments. It virtualizes data storage resources, so users can take control of their data, regardless of where and on what device the data is stored.

The development infrastructure supports exhaustive testing on supported platforms; plugin support for microservices, storage resources, authentication mechanisms, network protocols, rule engines, new API endpoints, and databases; and extensive documentation, training, and support services.

• iRODS: https://irods.org

• iRODS Consortium: https://irods.org/consortium

• RENCI: https://renci.org

Core Competencies

• iRODS implements data virtualization, allowing access to distributed storage assets under a unified namespace, and freeing organizations from getting locked in to single-vendor storage solutions.
• iRODS enables data discovery using a metadata catalog that describes every data object, collection, and every storage resource in the iRODS Zone.
• iRODS automates data workflows, with a rule engine framework that permits any action to be initiated by any trigger on any server or client in the Zone.
• iRODS enables secure collaboration, so users only need to log in to their home Zone to access data hosted on a remote Zone.

History

iRODS has a 25+ year history of funded projects.

Funders have included DARPA, NSF, DOD, DOE, LC, NARA, NASA, NOAA, USPTO, and LLNL.

https://irods.org/history

License

iRODS is released under a 3-clause BSD License.

Reporting Security Vulnerabilities

See SECURITY.md for details.

Links to elsewhere...

• https://github.com/irods
• https://docs.irods.org
• https://twitter.com/irods

irods_client_globus_connector's Issues

Request realpath feature

I see that it is possible to address files by both a path namespace as well as an object id, so depending on how that works it may also make sense to implement the realpath feature, which would enable path restrictions to work.

Checksum timeout errors when transferring data to and from 4.3.0 globus irods endpoints

Bug Report

iRODS Version, OS and connector Version

• iRODS server 4.3.0 and 4.2.11
• globus connect server: package 5.4.52, cli 1.0.34
• irods-gridftp-client-4.2.11.2-1 (the latest available)

All iRODS collections (4.3.0 and 4.2.11) are using the same globus endpoint.

What did you try to do?

We have been using for a while the Globus iRODS connector without major issues with a number of iRODS zones. We recently upgraded all zones except one to iRODS v4.3.0 and since then we have problems when transferring files with the checksum check activated (default mode in Globus) for the zones running iRODS 4.3.0 . The zone still running 4.2.11 is working fine.

Expected behavior

Transfers will be successful to/from Globus iRODS collections when checksum check is activated (default Globus mode)

Observed behavior (including steps to reproduce, if applicable)

This is what we have observed:

• The problem seems to appear with transfers involving multiple files not for single file transfers.
• The problem occurs both when the iRODS 4.3.0 endpoint is the source or the destination.
• When deactivating checksum check (check “do NOT verify file integrity after transfer”) transfers are done without errors.
• The same dataset transferred to/from an iRODS 4.2.11 works fine

The error in Globus interface is:

Error (transfer) Endpoint: VSC iRODS set.irods.icts.kuleuven.be (56dd39e2-ffae-4075-8354-ba8ed078dd59) Server: 134.58.8.37:443 Command: CKSM MD5 0 -1 /set/home/u0089722/Globus-tests/test-dataset/100MB.bin Message: The operation timed out --- Details: Timeout waiting for response

We have managed to reproduce the error with a test dataset with the following files:

1MB.bin 5MB.bin 10MB.bin 50MB.bin 100MB.bin 500MB.bin 1GB.bin 5GB.bin 10GB.bin

Where each file has been generated using the command:

dd if=/dev/urandom of=256GB.bin bs=1M count=X iflag=fullblock

and X is 1 5 10 50 100 500 1000 5000 10000 respectively.

In attachment (globus_irods_checksum_timeout.log) you can find the filtered gridftp.log of the transfer when debug log level was activated. Globus taskID : 1b14b91c-b786-11ed-a505-1f2a3a60e896

globus_irods_chechsum_timeout.log

We opened an issue to Globus support for the problem and they told us:

Our devs have taken a look at the outputs provided, and it appears that the process is hanging after computing the checksum while attempting to update the checksum metadata on the iRODS server. You'll want to discuss this further with iRODS support

Provide partial directory listings

We have had a request for the GridFTP plugin to provide the ability for partial directory listings. This issue is to track that request and to provide more information as necessary.

checksum updates thread is locked around sleep(1) which limits progress

found by @michaellink

Probable memory leak

• main
• 4-3-0-stable
• 4-2-stable

---

We suspect a memory leak in the irods globus connector. On a server that handles exclusively globus transfers through the irods connector, we see the following graph in memory usage:

We use the latest available version of the globus connect server and the 4-3-0-stable branch of this repository.

Add status update for long running checksum operations.

We have had a request for an enhancement to add status updates (percent complete) for long running checksum operations. This issue is to track the work on that.

need default CMake values for DEST_xxx_DIR

To alleviate the need to define these prior to building...

export DEST_LIB_DIR="/<preferred_path>"
export DEST_BIN_DIR="/<preferred_path>"
export DEST_ETC_DIR="/<preferred_path>"

Should be distribution-aware, in case default assumptions should be different.

Move base64_encode and base64_decode into plugin

• main
• 4-2-stable

---

I seem to be getting conflicts with base64_encode and base64_decode. To be sure we pick up the right versions, move this code into the plugin. Put the methods in the irods::globus namespace.

Housekeeping / Versioning / Whitespace

Move hash algorithms into globus connector code for 4.2.8

Move hash algorithms into globus connector code for 4.2.8

Use multithreaded transfers.

Data object should get `stale` state when transfer is interrupted

Bug Report

iRODS Version, OS and Version

4.3.0 almalinux8

ps. I am not sure whether this should be reported here or in the main irods repository.

What did you try to do?

• I terminated the task that transfers an object from outside to iRODS
• I terminated the task that transfers an object between two collections (copy ) in iRODS

Expected behavior

I expect interrupted transfers with errors in iRODS logs and also I expected objects exist in X/stale status

Observed behavior (including steps to reproduce, if applicable)

Transfers are terminated successfully and data objects have & status in irods and no error in the logs of iRODS

In line with other clients behavior, if a transfer to iRODS via globus is interrupted, the object status should be 'stale' instead of 'good'. This gets confused since data is partially written on destination not completely yet.

Logs in irods when a transfer via iCommands (or prc) is interupted:

[2023-06-09T13:09:24.440Z][icts-p-cloud-rdm-hev-2] irods stdout | {"log_category":"legacy","log_facility":"local0","log_level":"error","log_message":"Agent [368103] exiting with status = -4000","request_api_name":"DATA_OBJ_PUT_AN","request_api_number":606,"request_api_version":"d","request_client_user":"u0137480","request_host":"127.0.0.1","request_proxy_user":"u0137480","request_release_version":"rods4.3.0","server_host":"set.irods.icts.kuleuven.be","server_pid":368103,"server_timestamp":"2023-06-09T13:09:24.440Z","server_type":"agent"}
[2023-06-09T13:09:24.400Z][icts-p-cloud-rdm-hev-2] irods stdout | {"log_category":"legacy","log_facility":"local0","log_level":"info","log_message":"_partialDataPut: toread 4194304 bytes, 3932040 bytes read, errno = 0","request_api_name":"DATA_OBJ_PUT_AN","request_api_number":606,"request_api_version":"d","request_client_user":"u0137480","request_host":"127.0.0.1","request_proxy_user":"u0137480","request_release_version":"rods4.3.0","server_host":"set.irods.icts.kuleuven.be","server_pid":368103,"server_timestamp":"2023-06-09T13:09:24.400Z","server_type":"agent"}
[2023-06-09T13:09:24.413Z][icts-p-cloud-rdm-hev-2] irods stdout | {"log_category":"legacy","log_facility":"local0","log_level":"error","log_message":"[-]\t/irods_source/server/core/src/rsApiHandler.cpp:560:int readAndProcClientMsg(rsComm_t *, int) :  status [SYS_HEADER_READ_LEN_ERR]  errno [] -- message [failed to call 'read header']\n\t[-]\t/irods_source/lib/core/src/sockComm.cpp:198:irods::error readMsgHeader(irods::network_object_ptr, msgHeader_t *, struct timeval *) :  status [SYS_HEADER_READ_LEN_ERR]  errno [] -- message [failed to call 'read header']\n\t\t[-]\t/irods_source/plugins/network/src/ssl.cpp:528:irods::error ssl_read_msg_header(irods::plugin_context &, void *, struct timeval *) :  status [SYS_HEADER_READ_LEN_ERR]  errno [] -- message [read 0 expected 4]\n\n","request_api_name":"DATA_OBJ_PUT_AN","request_api_number":606,"request_api_version":"d","request_client_user":"u0137480","request_host":"127.0.0.1","request_proxy_user":"u0137480","request_release_version":"rods4.3.0","server_host":"set.irods.icts.kuleuven.be","server_pid":368103,"server_timestamp":"2023-06-09T13:09:24.413Z","server_type":"agent"}
[2023-06-09T13:09:24.368Z][icts-p-cloud-rdm-hev-2] irods stdout | {"log_category":"legacy","log_facility":"local0","log_level":"info","log_message":"_partialDataPut: toread 4194304 bytes, 917296 bytes read, errno = 0","request_api_name":"DATA_OBJ_PUT_AN","request_api_number":606,"request_api_version":"d","request_client_user":"u0137480","request_host":"127.0.0.1","request_proxy_user":"u0137480","request_release_version":"rods4.3.0","server_host":"set.irods.icts.kuleuven.be","server_pid":368103,"server_timestamp":"2023-06-09T13:09:24.368Z","server_type":"agent"}
[2023-06-09T13:09:24.431Z][icts-p-cloud-rdm-hev-2] irods stdout | {"log_category":"legacy","log_facility":"local0","log_level":"error","log_message":"[rsDataObjClose:803] - [Unknown iRODS error: [update_replica_size_and_throw_on_failure:463] - failed to get size in vault [error_code=[987234304], path=[/set/home/u0137480/1GB.bin], hierarchy=[default;netapp]]\n\n]","request_api_name":"DATA_OBJ_PUT_AN","request_api_number":606,"request_api_version":"d","request_client_user":"u0137480","request_host":"127.0.0.1","request_proxy_user":"u0137480","request_release_version":"rods4.3.0","server_host":"set.irods.icts.kuleuven.be","server_pid":368103,"server_timestamp":"2023-06-09T13:09:24.430Z","server_type":"agent"}
[2023-06-09T13:09:24.435Z][icts-p-cloud-rdm-hev-2] irods stdout | {"log_category":"legacy","log_facility":"local0","log_level":"error","log_message":"[-]\t/irods_source/server/core/src/rsApiHandler.cpp:560:int readAndProcClientMsg(rsComm_t *, int) :  status [SYS_HEADER_READ_LEN_ERR]  errno [] -- message [failed to call 'read header']\n\t[-]\t/irods_source/lib/core/src/sockComm.cpp:198:irods::error readMsgHeader(irods::network_object_ptr, msgHeader_t *, struct timeval *) :  status [SYS_HEADER_READ_LEN_ERR]  errno [] -- message [failed to call 'read header']\n\t\t[-]\t/irods_source/plugins/network/src/ssl.cpp:528:irods::error ssl_read_msg_header(irods::plugin_context &, void *, struct timeval *) :  status [SYS_HEADER_READ_LEN_ERR]  errno [] -- message [read 0 expected 4]\n\n","request_api_name":"DATA_OBJ_PUT_AN","request_api_number":606,"request_api_version":"d","request_client_user":"u0137480","request_host":"127.0.0.1","request_proxy_user":"u0137480","request_release_version":"rods4.3.0","server_host":"set.irods.icts.kuleuven.be","server_pid":368103,"server_timestamp":"2023-06-09T13:09:24.435Z","server_type":"agent"}
[2023-06-09T13:09:24.451Z][icts-p-cloud-rdm-hev-2] irods stdout | {"log_category":"legacy","log_facility":"local0","log_level":"error","log_message":"Agent process [368103] exited with status [1]","server_host":"set.irods.icts.kuleuven.be","server_pid":112,"server_timestamp":"2023-06-09T13:09:24.451Z","server_type":"agent_factory"}

remove sleep(1) in checksum calculation

very bad checksum performance on transfers with many small files

found by @michaellink

Request for new release containing the modification time issue patch

Would it be possible to make a new release of this plugin containing the fix for the modification patch issue.
We need to deploy it because some users are hitting this issue and they are waiting for the fix.
Having a new release will make our live easier.

Thank you!

Checksum algorithms need to support any case

When looking up the hashing strategy implementation, we are using the string that the user sent. This could be "MD5" or "md5", etc. The strategy implementation keys are all lowercase so whatever the user asks for needs to be converted to lowercase before looking up the implementation.

Data objects are sometimes being stuck in intermediate mode after transfers

After (presumably failed) transfer through the globus connector, data objects are being stuck in intermediate mode.

We believe that this isn't possible with the changes made for 4.3.1. This issue is both for continual investigation of that issue and to report specific scenarios which are causing that issue.

We will keep this open until we either find a specific root cause or determine that it is no longer an issue in 4.3.1.

Globus transfer checksum fails for files containing "where" in name

• main
• 4-3-0-stable
• 4-2-stable

---

If a file containing "where" in the name is uploaded, e.g. test_where.py, the transfer fails at computing the md5 checksum.

This is a revival of irods/irods#4697 but for the "where" keyword instead of the "select" keyword.
See the remark at https://github.com/irods/irods_client_globus_connector/blob/main/DSI/globus_gridftp_server_iRODS.cpp#L1472-L1480 for more context.

Please lowercase "where" as well until the parser is replaced in the core code.

When looking at checksum update time, use only replicas that are marked good.

Update the query performed to do the following:

iquest "SELECT META_DATA_ATTR_VALUE, META_DATA_ATTR_UNITS, DATA_MODIFY_TIME where COLL_NAME = '' and DATA_NAME = '' and META_DATA_ATTR_NAME = 'Globus::' and DATA_REPL_STATUS = '1'"

Deprecation error when compiling Globus plugin on Ubuntu 22

When compiling Globus plugin on Ubuntu 22 I got deprecation warnings for the following methods:

• MD5_Init
• MD5_Update
• MD5_Final
• SHA1_Init
• SHA1_Update
• SHA1_Final
• SHA256_Init
• SHA256_Update
• SHA256_Final
• SHA512_Init
• SHA512_Update
• SHA512_Final

To work around this error I had to disable the -Werror flag. After doing so it built and tests passed.

We need to update these methods as described here: https://www.openssl.org/docs/man3.1/man3/SHA512_Update.html

Note that irods core uses some of these methods. I think that the -Werror flag isn't enabled for those.

Transferring an object to/in iRODS throws `-808000` and `-358000`

Bug Report

iRODS Version, OS and Version

4.3.0 almalinux8

What did you try to do?

• I tried to transfer an object from outside to iRODS
• I tried to transfer an object between two collections (copy ) in iRODS

Expected behavior

Transfers to be completed successfully and and without seeing any error in iRODS logs

Observed behavior (including steps to reproduce, if applicable)

Transfers are completed successfully (data objects have & status in irods) but with an error in the logs of iRODS

[2023-06-01T14:25:26.454Z][icts-p-cloud-rdm-hev-2] irods stdout | {"log_category":"legacy","log_facility":"local0","log_level":"error","log_message":"[rsDataObjOpen_impl:904] - [OBJ_PATH_DOES_NOT_EXIST: Data object or replica does not exist [error_code=-808000, path=/ghum/home/u0137480/my_test_file.txt].\n\n] [error_code=[-358000], path=[/ghum/home/u0137480/my_test_file.txt], hierarchy=[]","request_api_name":"DATA_OBJ_OPEN_AN","request_api_number":602,"request_api_version":"d","request_client_user":"u0137480","request_host":"127.0.0.1","request_proxy_user":"globus","request_release_version":"rods4.3.0","server_host":"ghum.irods.icts.kuleuven.be","server_pid":167725,"server_timestamp":"2023-06-01T14:25:26.454Z","server_type":"agent"}

If I interpret it correctly, on each transfer we see errors because of this.

Could you let us know whether this is something that we should be worried about?

irods-externals-jansson not needed for 4.2.x

• 4-2-stable

---

The CMakeLists.txt has a dependency on the irods-externals-jansson package. This doesn't seem to be used and has already been removed and tested from 4.3.

Remove references to jansson from CMakeLists.txt and README.md. Test that everything behaves properly.

Update README for building plugin with latest Globus version

• main
• 4-3-0-stable
• 4-2-stable

---

Update README for building plugin with latest Globus version

Update dependencies to the latest version

Update irods dependencies to the latest version

Add SHA1, SHA-512, and ADLER-32. Use client setting.

1. Add SHA1, SHA-512, and ADLER-32.
2. Use client setting and calculate checksums on client.
3. Store checksums in metadata with timestamp.
4. Determine if recalculation by comparing the timestamp with object modify time (if metadata for that algorithm exists).

See [#9]

Change CMakeLists.txt to use normal iRODS plugin release scheme

This will apply to both the package name and the .so names.

Link to libssl_client.so

When using an SSL connection to iRODS, the plugin needs to link to libssl_client.so.

Update iRODS Globus plugin for 4.3

Hardcoded timeout parameters in parallel read/write code

In the parallel read/write cases, there are a couple of timeout parameters.

1. Twice waiting for a condition variable for the # of outstanding callbacks. One is waiting for the #outstanding to be 0. The other is waiting for it to be less than optimal_count. (These are set to 30 seconds.)

2. The circular buffer used when transferring the file to the server has a timeout when pushing and popping data. (This is set to 30 seconds.)

Should these be configurable or would that be confusing? If not, what is the best setting for these.

• These need to be long enough so that we don't have a timeout during normal operation. (30 seconds is more than enough for this it appears.)
• The shorter these are, the less time it takes for the plugin to notice if something went wrong/crashed.

Cannot rename data objects and collections via the globus interface

Bug Report

iRODS Version, OS and Version

4.3.0 almalinux8

What did you try to do?

Through the globus web interface,

• I tried to rename an object in iRODS
• I tried to rename a collection in iRODS

Expected behavior

Renamed data objects and collections in iRODS

Observed behavior (including steps to reproduce, if applicable)

Even though the globus interface shows objects are renamed, in fact they are not renamed and this can be verified when clicked refreshed list.

Automate testing

Right now all testing in manual. Add automated tests.

error in dependencies in Ubuntu repository

Bug Report

iRODS Version, OS and Version

• OS: Ubuntu 18.04
• iRODS: 4.2.8

What did you try to do?

• apt update

Expected behavior

• apt update should finish with exit code 0.

Observed behavior (including steps to reproduce, if applicable)

Problem parsing dependency 21
Error occurred while processing irods-gridftp-client (NewVersion2)
Problem with MergeList /var/lib/apt/lists/packages.irods.org_apt_dists_bionic_main_binary-amd64_Packages
The package lists or status file could not be parsed or opened.
Can't call method "policy" on an undefined value at /usr/bin/apt-show-versions line 53.
Reading package lists... Error!
E: Problem executing scripts APT::Update::Post-Invoke-Success 'test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i'
E: Sub-process returned an error code
E: Problem parsing dependency 21
E: Error occurred while processing irods-gridftp-client (NewVersion2)
E: Problem with MergeList /var/lib/apt/lists/packages.irods.org_apt_dists_bionic_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.

The problem is, that the list of dependencies for irods-gridftp-client contains irods-runtime (= ), but it should contain irods-runtime (= 4.2.8)

The problem occurred after an update of the repository made on May 11, 22:45.

CMake consistency sweep

Update README

I noticed some updates were needed for the readme.

1. The references to GLOBUS_GridFTP needs to change to irods_client_globus_connector.
2. The latest globus headers without the "register" keyword are not downloaded when using the current instructions. Added steps to enable their repos.
3. Noticed one typo.

missing variable initialization

there are missing initializations on some exit guard parameters which can result in crashes if globus_gridftp_server_finished* gets called multiple times.

@michaellink saw a consistent crash in listings/stat().

Is timestamp preservation possible for transfers to iRODS?

A user has noticed that timestamp preservation doesn't work on transfers to our iRODS servers.
This is the error in question:

Error (transfer)
Endpoint:
Server: 134.58.8.4:443
File:
Message: This server version does not support timestamp preservation

Details: Sanity check did not pass - MFMT failed

My question is: is timestamp preservation something that the iRODS-Globus-connector takes into account?
Or does this feature not exist?
I'm curious because unlike other filesystems, iRODS stores the timestamps in the iCAT database.

If this functionality exists, the reason may very well lay outside of the iRODS-Globus connector.
But we want to avoid digging into this if we aren't sure it actually exists.
In the past, we also had this issue with one of our non-iRODS endpoints, but since that server is gone, we cannot reproduce anymore.

Best regards,

Jef

Add lib/irods_login/include/clientLogin.hpp to git.

Forgot to add it.

Crash when attempting to query checksum metadata for certain filenames

With filename /tempZone/home/mlink/selectable.cpython-36.pyc, a checksum query crashes in irods::query:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f8276fe5700 (LWP 8876)]
0x00007f828fc0d387 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install globus-connect-gridftp-server-progs-15.93~rc1-1.el7+gcs5.x86_64
(gdb) bt
#0  0x00007f828fc0d387 in raise () from /lib64/libc.so.6
#1  0x00007f828fc0ea78 in abort () from /lib64/libc.so.6
#2  0x00007f82818f1a95 in __gnu_cxx::__verbose_terminate_handler() ()
   from /lib64/libstdc++.so.6
#3  0x00007f82818efa06 in ?? () from /lib64/libstdc++.so.6
#4  0x00007f82818efa33 in std::terminate() () from /lib64/libstdc++.so.6
#5  0x00007f82818efc53 in __cxa_throw () from /lib64/libstdc++.so.6
#6  0x00007f8283b4899b in irods::query<RcComm>::gen_query_impl::gen_query_impl(RcComm*, int, int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int) ()
   from /usr/lib64/libglobus_gridftp_server_iRODS.so
#7  0x00007f8283b47de2 in std::__1::shared_ptr<irods::query<RcComm>::gen_query_impl> std::__1::shared_ptr<irods::query<RcComm>::gen_query_impl>::make_shared<RcComm*&, unsigned long&, unsigned long&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int&>(RcComm*&, unsigned long&, unsigned long&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, int&) ()
   from /usr/lib64/libglobus_gridftp_server_iRODS.so
#8  0x00007f8283b45b60 in irods::query<RcComm>::query(RcComm*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, unsigned long, irods::query<RcComm>::query_type, int) ()
   from /usr/lib64/libglobus_gridftp_server_iRODS.so
#9  0x00007f8283b11899 in irods::query<RcComm>::query(RcComm*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned long, unsigned long, irods::query<RcComm>::query_type, int) ()
   from /usr/lib64/libglobus_gridftp_server_iRODS.so
#10 0x00007f8283b008dc in globus_l_gfs_iRODS_command ()

and I get a bad result duplicating that query with iquest:

$ iquest "SELECT META_DATA_ATTR_VALUE, META_DATA_ATTR_UNITS, DATA_CREATE_TIME where COLL_NAME = '/tempZone/home/mlink' and DATA_NAME = 'selectable.cpython-36.pyc' and META_DATA_ATTR_NAME = 'GLOBUS::MD5' and DATA_REPL_STATUS = '1'"
 ERROR: iquest Error: queryAndShowStrCond failed status = -1107000 NO_COLUMN_NAME_FOUND

However, I'm able to imeta add and imeta ls the same metadata, and then iquest can show it when querying the collection without the DATA_NAME constraint:

$ iquest "SELECT DATA_NAME, META_DATA_ATTR_VALUE, META_DATA_ATTR_UNITS, DATA_CREATE_TIME where COLL_NAME = '/tempZone/home/mlink' and META_DATA_ATTR_NAME = 'GLOBUS::MD5' and DATA_REPL_STATUS = '1'"                                                 
DATA_NAME = selectable.cpython-36.pyc
META_DATA_ATTR_VALUE = 4cffc8b698e593ba3de977d88e14329f
META_DATA_ATTR_UNITS = 1653083665
DATA_CREATE_TIME = 01653083447
------------------------------------------------------------

This seems to be an issue for any filename starting with select, and possibly other keywords. It probably isn't exclusive to the DSI, but maybe in this case the crash can be avoided and the failed query would just fall back to recomputing the checksum.

Mike

Overwriting a file does not update its modify time

• main
• 4-2-stable

---

When overwriting an existing file with the DSI, the modification time is not updated. One problem this leads to is that the previously cached checksum metadata is considered current, instead of calculating a new one.

I reproduced this on 4.2.11.1, and confirmed that iput does update the modification time.

Mike

Update debian libssl version in CMakeLists.txt from 1.0.0 to 1.1

• main
• 4-3-0-stable

---

Update debian libssl version in CMakeLists.txt from 1.0.0 to 1.1. This is required for Ubuntu 20.

This was tested for Ubuntu 18 as well.

Initialize the pthread_mutex

When creating the pthread_mutex, initialize it to PTHREAD_MUTEX_INITIALIZER