Create a sym link in EOS namespace for tape data

Hi,

SNOPLUS, a small high energy physics VO based in Canada, would like to recall ~200TB of tape data from RAL. The VO’s top-level dir in the EOS namespace is “/eos/antares/prod/snoplus”.

However, the data management system that will be used for this purpose, DIRAC, cannot cope with the abbreviated VO name “snoplus” and it expects (hard-coded) the full VO name “snoplus.snolab.ca”

My question: is it possible to create a symbolink link like for example
/eos/antares/prod/snoplus/ → /eos/antares/prod/snoplus.snolab.ca/

From the EOS docs - file — EOS CITRINE documentation - it looks like that this can be done only on a file by file basis but I am not sure.

Can you please confirm? And, is there any danger for the tape data from this change?

Thanks,

George

Just to say that following Andrea’s suggestion in Create a sym link in EOS namespace for tape data - #5 by apeters - EOS Community the following EOS mapping (on our preprod instrance where the “real” is /eos/antarespreprodfac/factest/)
eos map ls
/eos/antarespreprodfac/factest.rl.ac.uk/ => /eos/antarespreprodfac/factest/

appears to have worked as expected.

Issuring a prepare for “/eos/antarespreprodfac/factest.rl.ac.uk/testfile6.img” resulted in the CTA Frontend workflow event for the real file “/eos/antarespreprodfac/factest/testfile6.img”

250410 12:01:06 time=1744282866.714830 func=open                     level=INFO  logid=1a1691c2-15fb-11f0-9daa-e8ebd3410d14 unit=mgm@antares-eos97.scd.rl.ac.uk:1094 tid=00007f98903f7640 source=XrdMgmOfsFile:548              tident=root.59396:454@cta-adm-preprodfac sec=sss   uid=0 gid=0 name=daemon geo="" op=read path=/proc/user/ info=mgm.cmd=fileinfo&mgm.path=/eos/antarespreprodfac/factest.rl.ac.uk/testfile6.img
250410 12:01:57 time=1744282917.613138 func=doPrepare                level=INFO  logid=386d0c14-15fb-11f0-8c8a-e8ebd3410d14 unit=mgm@antares-eos97.scd.rl.ac.uk:1094 tid=00007f98985d8640 source=PrepareManager:222             tident=<service> sec=sss   uid=1200 gid=1200 name=factest geo="" msg="checking file exists" path="/eos/antarespreprodfac/factest.rl.ac.uk/testfile6.img"
250410 12:01:57 time=1744282917.613365 func=triggerPrepareWorkflow   level=INFO  logid=386d0c14-15fb-11f0-8c8a-e8ebd3410d14 unit=mgm@antares-eos97.scd.rl.ac.uk:1094 tid=00007f98985d8640 source=PrepareManager:468             tident=<service> sec=sss   uid=1200 gid=1200 name=factest geo="" msg="about to trigger WFE" path="/eos/antarespreprodfac/factest/testfile6.img" info=""
250410 12:01:57 time=1744282917.613423 func=Event                    level=INFO  logid=386d0c14-15fb-11f0-8c8a-e8ebd3410d14 unit=mgm@antares-eos97.scd.rl.ac.uk:1094 tid=00007f98985d8640 source=Event:111                      tident=georgep.1027511:452@lcgui05.gridpp.rl.ac.uk sec=sss   uid=1200 gid=1200 name=factest geo="" subcmd=event event=sync::prepare path=/eos/antarespreprodfac/factest/testfile6.img fid=0
250410 12:01:57 time=1744282917.613479 func=HandleProtoMethodEvents  level=INFO  logid=static.............................. unit=mgm@antares-eos97.scd.rl.ac.uk:1094 tid=00007f98985d8640 source=WFE:1616                       tident= sec=(null) uid=99 gid=99 name=- geo="" default SYNC::PREPARE /eos/antarespreprodfac/factest/testfile6.img cta-front05.scd.rl.ac.uk:10955 fxid=0bf32cfd mgm.reqid="044682f6d87c:88e44a97.67f78c13:3:1744282917"
250410 12:01:57 time=1744282917.648414 func=SendProtoWFRequest       level=INFO  logid=static.............................. unit=mgm@antares-eos97.scd.rl.ac.uk:1094 tid=00007f98985d8640 source=WFE:2774                       tident= sec=(null) uid=99 gid=99 name=- geo="" protoWFEndPoint="cta-front05.scd.rl.ac.uk:10955" protoWFResource="/ctafrontend" fullPath="/eos/antarespreprodfac/factest/testfile6.img" event="sync::prepare" timeSpentMs=34 msg="Sent SSI protocol buffer request"

Files can also be recalled using the original path (sanity check).

Andreas said that this namespace change is safe and it looks like it is indeed.

Unless you have a serious objection, I will make a similar change in production

Hi George,
I started with maps but moved to more standard sym links: eos ln -s works great for eosctaalice instance at CERN to solve the exact same issue. The great thing here is that everyone is already familiar with ln -s.

Best regards,
Julien Leduc