Filesystem - no function to create hard links?

[andyferris]

Unless I missed it, it seems we don't have a way to create hard links in the filesystem. I was suprised because we use libuv and Node has fs.linkSync(existing_path, new_path) and friends. I'm guessing adding this might not be too difficult?

See also https://discourse.julialang.org/t/create-hard-links-in-julia-is-there-another-way-than-via-external-command-run/12908

[c42f]

A survey of other language APIs:

• Node hasfs.linkSync(existingPath, newPath) (also async-related fs.link and fsPromises.link) https://nodejs.org/api/fs.html#fs_fs_linksync_existingpath_newpath
• Python has the quite complex API os.link(src, dst, *, src_dir_fd=None, dst_dir_fd=None, follow_symlinks=True) https://docs.python.org/3/library/os.html#os.link
• Java has createLink(link, existing) https://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#createLink(java.nio.file.Path,%20java.nio.file.Path)
• C++ has std::create_hard_link(target, link) https://en.cppreference.com/w/cpp/filesystem/create_hard_link (What's this? Actual batteries-included functionality in the C++ standard library? I must have been away for a while!)

It would seem natural to add this as hardlink(target::AbstractString, link::AbstractString) in analogy to the current symlink (C++ has seen fit to call this "hard link" in their API). Presumably the extra features available in the python API (os fd's) could be supported by allowing file descriptor types for target and link, if necessary later.

[andyferris]

Thanks Chris. Yeah I agree with that naming - hardlink should be a little more obvious in meaning than link would be.

(Though I personally always found the target and link terminology super confusing and always second-guess the ordering, even for ln)

[c42f]

a little more obvious in meaning than link would be.

Also I think it would be unfortunate to export a completely generic name like link from Base and assign it a very concrete and relatively uncommonly-used meaning.

Though I personally always found the target and link terminology super confusing and always second-guess the ordering, even for

You're not the only one!

It seems to me that existing is the more obvious name here (unfortunately... the target technically doesn't have to exist for symlink, with the possible exception of windows). There's also src and dst to consider, in analogy to cp() (and python's os.link) which I think could be even better. Perhaps a little less technically correct, but hopefully much more obvious:

hardlink(src::AbstractString, dst::AbstractString)

[StefanKarpinski]

Does Windows support hardlinks?

[andyferris]

Yes, they are supported in NTFS.

[StefanKarpinski]

Ok then it seems sensible to have a hardlink(src, dst) function. I agree that the argument order can be confusing, but we may as well be consistent with the standard confusing order.

[barucden]

It amounts to

• creating a new function (jl_fs_hardlink?) that calls libuv,
• creating (and exporting) a Julia function (hardlink(src, dst)) which calls the new function,
• and adding tests,

right? I think I could do that if nobody's working on it already.

[andyferris]

That sounds about right to me. I haven’t started working on it - thank you for offering!

[StefanKarpinski]

Yes, that sounds right. I would mimic what's done for jl_fs_symlink.