Forum OpenACS Development: Symlinks

Collapse
Posted by Malte Sussdorff on
I just realized that file-storage has a bug when it comes down to symlinks. Here is why:

- In folder-chunk.tcl the display of a symlink is replaced by the original file_id of the linked to file. This is great, but when you want to delete the symlink it actually deletes the original file as the original file_id is used everywhere and the symlink_id is gone. We fixed this, but not sure if this needs to go into 5.2 (I guess no) or in 5.3 (I guess yes).

- Additionally, when you add a new version for a symlink, you do not want to overwrite the original file, but create a new file instead of the symlink. So what we did is to delete the symlink and reuse the symlink_id as the item_id to upload the new file.

I don't think anyone really bothers because before we touched symlinks folder-chunk.tcl was not even able to display a symlink, but that does not make our thinking absolutely right :).

Feedback requested, especially as this is a serious bug in 5.2 if someone actually uses symlinks.

Collapse
2: Re: Symlinks (response to 1)
Posted by Stan Kaufman on
Symlinks have at least one other problem -- or at least an incompletely implemented feature -- that makes their behavior unlike the "ln -s source_file target_file" behavior that presumably they should emulate: they work only on individual files (well, cr_items). It is not possible to symlink a folder, though it seems as if it should be.

We discussed this last year and there were different opinions about how to approach this. I think it would be great if symlinks were actually finished so that they work like "ln -s" -- one way or another.