Good questions. It requires some consideration.
- add, edit and/or delete symlinks
- store such information somewhere (in database or in the symlink file)
- when clicked such symlink file, you should be redirected to the file which is set as shortcut - but in the same panel or in the second panel?
1. I don't think edit would/could/or should work on the symlink itself. The edit and view buttons should work on the target exactly as they do at present with symlinks. The actual symlink can only be added or deleted.
1a. With delete on the symlink I think you would need a dialogue
"Do you wish to delete just the link, or the link and the target file? Link Only/Link & Target"
You might want to remove the only the link from a folder leaving the target for example if the folder was being used to display an image gallery consisting of set of images some of which were actually stored in different folders. In this case you would probably want to leave the target alone. In other case you might want to delete both the link and the target.
2. At first glance it doesn't seem necessary to add anything to the database, you can detect if a file or folder is a link with php is_link() or (is_link && is_dir) and display a different icon (the standard one with a chain link on it would be normal).
2a. However there is a problem if the target file is deleted without deleting the link. There is no easy way to detect if a file is the target of a symlink without traversing the whole file system using for each $file where $target is the name of the file you are about to delete:
Code: Select all
if readlink($File::Find::name) eq $target;
You probably don't want to have to do this every time someone deletes a file as it might be a bit of a performance overhead (although only 3 lines of code in a recursive function). So for this reason you might want to have a table of symlinks and targets that have been created within Commander - in this case you could perform a scan of the whole filesystem and pull in details of every symlink created outside commander. But then there is a danger of your table getting out of date if a symlink or target gets deleted outside Commander. And in any case you'd still have to look up the file in the db to see if it was a link target before deleting.
So perhaps scanning the system on every delete is not so bad. Maybe a configuration option to turn off/on symlink support is the way to go.
2b. Perhaps the ideal option is simple to scan the entire system looking for links when Commander is opened and storing that either as a array or in a temp database table for as long as commander is open. There might be errors if changes were made by another user or using a different browser while Commander was open, but these would self correct when it was closed and reopened and the system re-scanned.
3. My feeling is that it should bring up the target in the second panel if it is a file. Currently if the link is to a folder then clicking on it opens the target folder in the same pane - for consistency this should change to opening the target folder in the second pane and leave the first pane as is.
Other points -
5. The attributes button could be enhanced to show the path and name of the target if the item is a link. If the data is available, eg by scanning the system when Commander opens, then also showing if the selected item is itself the target of a lnk would be useful.
6. If a link is renamed moved it should still work so that is ok. If a target is moved or renamed then the link is broken, so you need to detect if the file is a target and issue a warning - or ideally simply replace any link(s) with a new one to the new target location. See discussion on Delete above
7. View and Edit and Unpack and Download should operate on the target (as currently happens)
8. Copy should operate on the link. Or possibly ask if to copy the link or the target. If you are into using links then you probably don't want to copy the file but just the link.
9. Move - see rename discussion above
10. New Folder and Upload - see 3 above. If clicking a folder name that is a link opens the folder in the second pane then new folders are only ever created in real folders and upload only ever works in real folders.
11. Delete - see discussions above
12. New button - Create Link (f12?). The link will be created in the current pane using the target selected in the second pane. Dialogue needs to ask for a name for the link. Personally I use a convention of link names with 's-' and the target filename. This could be a configuration option to have a prefix. In any event if it is a file then the extension part needs to be preserved or unexpected results may happen.
I think that just about covers it. As always a lot more work than it might appear at first sight. Feel free to contact me if you would like some help with this. I can't imagine that it is a high priority as not many people are aware of the power of symlinks. On the other hand adding this facility would be a real USP for Commander.
Of course there is a whole separate set of issues if the site happens to be running on a windows host....lets not even go there!
Cheers
RogerCO
