Forgot your password?
Views
Problem description
Current ELFI code prescribes the use of ln for creating additional replicas (SURLs?) of existing LFNs?, while cp must be used to copy®ister a Grid-file under a new Logical File Name.
Objections have been raised that this is counter-intuitive and is not coherent with the rest of the filesystem metaphor that underlies ELFI's approach to Grid storage. In particular:
The cp command acts in a non-uniform way:
# this works and registers a new LFN cp SE1/logical/file/name SE2/other/logical/file/name # this does not work! cp SE1/logical/file/name SE2/logical/file/nameOne would expect that cp creates a replica of /logical/file/name in the second case.
Same for ln:
# this works and creates a replica ln LFC/lfn SE2/lfn # this does not work! ln LFC/lfn1 LFC/lfn2It is highly confusing that commands fail in one case and work in the other (especially when they work in both cases on any local fs).
The ln command reverses the metaphor: on the UNIX fs the following code:
# local UNIX fs ln /file1 /file2will produce files that share the same physical content location; that is, modifying one file's content will instantly yield the same change to the other file's content.
Whereas on ELFI:
# ELFI ln LFC/lfn SE/lfncreates a new SURL (physical location); two different replicas do not share content -- indeed, replicas are different files with the same name! That is, the reverse of what's on local UNIX fs...
Proposed solution
Copying from one SE to another, preserving LFN will create a replica:
# create new replica on SE2 cp SE1/lfn SE2/lfn
Fail ln with ENOTSUP ("Operation not supported").
