Cannot recursively remove directory with files over xrootd. Only the files get removed but not the folders.

[ikrommyd]

Locally it woks:

~/tmp via 🅒 awkward-coffea
❯ ls

~/tmp via 🅒 awkward-coffea
❯ mkdir a

~/tmp via 🅒 awkward-coffea
❯ mkdir a/b

~/tmp via 🅒 awkward-coffea
❯ touch a/b/file.txt
 
~/tmp via 🅒 awkward-coffea
❯ ipython
iPython 3.13.7 | packaged by conda-forge | (main, Sep  3 2025, 14:24:46) [Clang 19.1.7 ]
Type 'copyright', 'credits' or 'license' for more information
IPython 9.5.0 -- An enhanced Interactive Python. Type '?' for help.
Tip: Use `--theme`, or the `%colors` magic to change IPython's themes and colors.

In [1]: import fsspec

In [2]: fs, token, path = fsspec.get_fs_token_paths(".")

In [3]: path
Out[3]: ['/Users/iason/tmp']

In [4]: fs.rm("a", recursive=True)

In [5]: exit

~/tmp via 🅒 awkward-coffea took 55s
❯ ls

If I do the same on the LPC cluster for instance

➜  ikrommyd pwd
/eos/uscms/store/user/ikrommyd
➜  ikrommyd mkdir a
➜  ikrommyd mkdir a/b
➜  ikrommyd touch a/b/file.txt

And then try to remove the directory recursively with fsspec

In [1]: import fsspec

In [2]: fs, token, path = fsspec.get_fs_token_paths("root://cmseos.fnal.gov//store/user/ikrommyd/tmp")

In [3]: path
Out[3]: ['/store/user/ikrommyd/tmp']

In [4]: fs.rm("/store/user/ikrommyd/tmp/a", recursive=True)

I get this error

File ~/micromamba/envs/awkward-coffea/lib/python3.13/site-packages/fsspec_xrootd/xrootd.py:372, in XRootDFileSystem._rm_file(self, path, **kwargs)
    370 status, _ = await _async_wrap(self._myclient.rm)(path, self.timeout)
    371 if not status.ok:
--> 372     raise OSError(f"File not removed properly: {status.message}")

OSError: File not removed properly: [ERROR] Server responded with an error: [3016] Unable to remove /store/user/ikrommyd/tmp/a; Is a directory

and if we look at the tree on LPC, the file gets deleted but not the folders.

➜  tmp pwd
/eos/uscms/store/user/ikrommyd/tmp
➜  tmp ls
a
➜  tmp tree
.
└── a
    └── b

2 directories, 0 files

Is this an xrootd feature or a bug here?

[nsmith-]

I don't know if this is expected or related to #13