cern-fts/gfal2-util

CLI for gfal2

gfal2-util's Issues

CommandRM doesn't run base.CommandBase.__init__

as per the issue title, the gfal2_util.rm.CommandRM class implements its own __init__ method, which doesn't call that of the base class.

As a result, variables defined in the CommandBase.__init__ method are not initialized for CommandRM and, if the gfal-rm takes too long, it fails at line 178 with the following exception:

Traceback (most recent call last):
  File "/bin/gfal-rm", line 37, in <module>
    sys.exit(Gfal2Shell().main(sys.argv))
  File "/usr/lib/python2.7/site-packages/gfal2_util/shell.py", line 74, in main
    return inst.execute(command_func)
  File "/usr/lib/python2.7/site-packages/gfal2_util/base.py", line 178, in execute
    if self.progress_bar is not None:
AttributeError: 'CommandRm' object has no attribute 'progress_bar'

I can provide a pull request to fix this issue.

Please, let me also know if you rather prefer this issue to be opened on CERN GitLab.

renaming a directory to its own subdirectory deletes it instead

gfal2-util 1.5.3

gfal-rename /path/to/source /path/to/source/sub

seems to permanently remove the source directory

Modern way to "bring online"?

I noticed that the command to bring data online from tape storage is legacy, but there were no modern solutions/alternatives provided in the description. Is there a better way to achieve this, or is it still suggested to just use the legacy command? My only concern is that the legacy command may become deprecated in the future and disappear.

When we do transfers via the FTS, that has a --bring-online flag, but we only use that for moving bulk data between sites. Our collaborators use the gfal utilities to access data. Thanks!

Segmentation fault for gfal-copy with gsiftp on RHEL-8

Hello GFAL developers,

we've installed a new VM with RHEL-8 to run our regular transfer tests using the gfal2-tools. They used to run just fine on SL-7, but now our gfal-copy commands randomly fail with Segmentation faults exclusively with the gsiftp transfer protocol (see attached example log).

So far, no core dumps were produced - we're trying to adjust system limits and kernel parameters to enable that. Other relevant information you might need...

$ python3 --version
Python 3.6.8

$ rpm -qa gfal2*
gfal2-plugin-file-2.21.5-1.el8.x86_64
gfal2-plugin-gridftp-2.21.5-1.el8.x86_64
gfal2-2.21.5-1.el8.x86_64
gfal2-plugin-http-2.21.5-1.el8.x86_64
gfal2-plugin-srm-2.21.5-1.el8.x86_64
gfal2-plugin-xrootd-2.21.5-1.el8.x86_64
gfal2-util-scripts-1.8.0-1.el8.noarch

$ uname -a
Linux gm-1-kit-e 4.18.0-513.5.1.el8_9.x86_64 #1 SMP Fri Sep 29 05:21:10 EDT 2023 x86_64 x86_64 x86_64 GNU/Linux

Do you have other hints on what we should check to find out more information for you?

Best regards,
Xavier.

gfal-ls and root://

I opened an issue with gfal2: cern-fts/gfal2#20
but it may be better placed here.
Please move if you think it fits better here.