On Fri, 10 Jan 2014 12:01:10 -0800 John Andersen wrote:

On 1/10/2014 11:42 AM, A. den Oudsten wrote:

...

When I trie to make a symbolic link I get the message: The symbolic link /var/run/media/FREECOM HD/........./Bad.jpg could not be made, check permissions. In the documentation I just learned: On Linux, the permissions of a symbolic link are not used in any operations; the permissions are always 0777 (read, write, and execute for all user categories), and can't be changed. Please help me further!! Thanks in advance Andr� den Oudsten

The permissions of the symbolic link have nothing to do with your error message.

You got this error because you tried to create this link in a location where you did not have authority to write.

Note that creating across file systems probably is less than ideal, especially when the source is on removable media. You end up chaseing your tail in the future when you can't open the link.

Hi André, John's diagnosis and suggestions are right on target (pardon the pun.) I want to address your confusion over symbolic link permissions. The permissions are 0777 because their role is to be 'transparent.' In effect, it is the target's permissions that are inherited and conveyed to users and the surrounding environment. If you stop to think about it, the links wouldn't function properly otherwise. It is fairly easy to familiarize yourself with the use of symbolic links. Place some files of various types and with differing permissions in a test directory (somewhere safe in your user space.) Then create symbolic links to them so you can examine how they function. hth & regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 12 Jan 2014 20:27:02 +0100 Bernhard Voelker wrote:

On 01/12/2014 04:20 PM, Carl Hartung wrote:

...

the links wouldn't function properly otherwise.

Off-question, maybe, but just FYI: Per definition, symbolic links do not necessarily have to "function", i.e. to be resolvable. A symbolic link could hold any information you like (restricted by length, and no binary NULL in there, of course).

For example, you can store the current uptime in a symlink:

$ ln -s "$(uptime)" my-uptime-in-a-symlink ls -ldog my-uptime-in-a-symlink $ ls -ldog my-uptime-in-a-symlink lrwxrwxrwx 1 67 Jan 12 20:25 my-uptime-in-a-symlink -> 20:25pm up 1 day 7:17, 9 users, load average: 0.25, 0.24, 0.19

Look at those permissions! <-- On Topic bit for the OP :-) Your example _does_ leave a broken symbolic link cluttering up the filesystem, Berny. "touch" is a lot less messy. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/13/2014 12:02 AM, Bernhard Voelker wrote:

Of course it's a dangling symlink - that was the aim of the demonstration: a symlink does not necessarily have to resolve to an existing file system object.

And this is not bad, by the way, and can be used to advantage. On one job (consultant to a discovery proceeding) we had a huge cache of documents on DVDs. Many DVDs. Lawyers needed to build on the fly links to accessing something they found interesting. Mostly We were able to search these, and create a directory full of soft links to the actual DVDs, but also train some of the paralegals to drag and drop, creating soft links to things they found. These would work while that DVD was in the Attorney’s drive but would show unresolved (or zero size) when a different DVD was inserted. I don't recall why they didn't copy the entire documents of interest but there was some reason they weren't allowed to do this. -- Explain again the part about rm -rf / -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org