# symlink at 8-RELEASE



## Seeker (Feb 12, 2010)

```
# touch FILE (-rw-r--r--)
# ln -s FILE SLINK (lrwxr-xr-x)
```



> If you have a file, foo, and a symlink to that file, bar, then this command will always succeed.
> % chmod g-w bar
> 
> However, the permissions on foo will not have changed.


That is really strange as I actually get file chmod-ed

```
# chmod 0777 SLINK

lrwxr-xr-x  1 root  wheel  -    4B Feb 12 21:39:02 2010 SLINK -> FILE
-rwxrwxrwx  1 root  wheel  -    0B Feb 12 21:38:41 2010 FILE
```
Also I've found:


> There are nine system calls that do not follow links, and which operate on the symbolic link itself. Like lchmod(2)




```
# lchmod 0777 SLINK
lchmod: Command not found.
```
This is a total mess!


----------



## knarf (Feb 12, 2010)

I can not reproduce your problem:


```
% touch file
% ln -s file link
% ls -lF
total 1
-rw-r--r--  1 knarf  wheel  0 Feb 12 22:07 file
lrwxr-xr-x  1 knarf  wheel  4 Feb 12 22:07 link@ -> file
% chmod -w link 
% ls -lF
total 1
-r--r--r--  1 knarf  wheel  0 Feb 12 22:07 file
lrwxr-xr-x  1 knarf  wheel  4 Feb 12 22:07 link@ -> file
```

This is 8.0-RELEASE-p2. Tested with zfs and ufs.

The '(2)' means it's a system call to be used in your favourite programming language. You can only use programs out of (1) and (8) in your shell.

mdoc(7) gives you an overview about the meanings of the chapter numbers, search for TITLE MACROS.

Bye,
Knarf


----------



## fronclynne (Feb 12, 2010)

Where did you read 





> If you have a file, foo, and a symlink to that file, bar, then this command will always succeed.
> % chmod g-w bar
> 
> However, the permissions on foo will not have changed.


 ?

From chmod(1)

```
-h      If the file is a symbolic link, change the mode of the link
             itself rather than the file that the link points to.
```

Which would indicate to me that the normal behaviour is to update the source file rather than the target link.

symlink(7) seems to agree with me.


----------



## Seeker (Feb 12, 2010)

knarf said:
			
		

> I can not reproduce your problem:
> 
> ```
> % touch file
> ...


You *DID* reproduced my problem 
By chmod-ing LINK, you actually edited FILE, not a link.


			
				fronclynne said:
			
		

> Where did you read  ?


You don't wana know! FreeBSD's official FAQ!


----------



## knarf (Feb 12, 2010)

Seeker said:
			
		

> You *DID* reproduced my problem
> By chmod-ing LINK, you actually edited FILE, not a link.



Sorry if I misunderstood your problem, but that's the way it should work.

If you want to change the permissions of the link, use `$ chmod -h`.

Changing the permissions of a symlink does not make sense most of the time. It's too easy to create another symbolic link pointing to the same file or just access the file directly.

It's like the 'forbid printing' feature in PDF readers where the feature is handled by the client.

Knarf


----------



## Seeker (Feb 12, 2010)

Symlinks actually don't have permissions at all.
So [CMD="chmod"]-h[/CMD] is just an _"eye candy"_
But I need it to recreate freebsd's symlink with exact symlink properties, which were in this case 0777


----------



## aragon (Feb 12, 2010)

Seeker, anyone who reads the chmod man pages and sees the command's real behaviour can see that the FAQ is obviously outdated or just mistaken.  Spare us the ego fed drama routine, get off the stage, and go be constructive with GNATS.


----------



## sixtydoses (Feb 13, 2010)

@Seeker

Use hard link if you want the changes of permission gets effective on the symlink file as well.


----------



## Seeker (Feb 13, 2010)

aragon said:
			
		

> Seeker, anyone who reads the chmod man pages and sees the command's real behaviour can see that the FAQ is obviously outdated or just mistaken.  Spare us the ego fed drama routine, get off the stage, and go be constructive with GNATS.


You are over reacting!
I am still WinXP user and only knew an existance of symlinks and basicaly what symlinks is. To me it is similar to Win shortuct.
This post was my learning path! So that was a reason for going into details!
And finally facts are facts! What I felt upon saying those facts is irrelevant. 2+2 will still be 4.


----------



## DutchDaemon (Feb 13, 2010)

Seeker, I can see aragon's point. You've opened several threads already where you introduced quite a lot of verbal drama and noise because you didn't understand something and wanted to blame the world. Look at threads like "Is freebsd-update, really so retarded" and "constant MASSIVE data/files losses on HDD!", and now even this slight hitch leads to "This is a total mess!". Tone it down a little.


----------



## Seeker (Feb 13, 2010)

Ok, ok, I see your point, DutchDaemon. 
It is simply, that I am still WinXP users and when I wana something to work, that happens really fast under win.

Here under freebsd, I must invest immense, (compared to my experience under win) amounts of time in reading, studying, various mans, handbook, forums, even for a slightest things.

PS: I accept your comment for all my threads, but I really think "constant MASSIVE data/files losses on HDD!" was fully justified, as it really was my worst experience under FBSD. Duh! Worse then any other experience under WinXP!


----------



## DutchDaemon (Feb 13, 2010)

Sure, but there you chose to run -STABLE as a relative newbie, which is contrary to common sense. You'll need quite a lot of dexterity to notice, handle and solve errors on a -STABLE platform without nuking your entire installation. I've never had a -STABLE gone awry, but that's probably because I caught errors and fixed them before they became fatal. That requires a bit of a background and 'instinct' in FreeBSD which you may not yet possess. I'm sure it was a nasty experience, but it was one you signed up for .. so take it slowly and avoid taking too much risk.


----------



## fronclynne (Feb 14, 2010)

Well, it is rather poor PR if the FAQ is dead wrong, which it is, in this case.


----------



## DutchDaemon (Feb 14, 2010)

Of course, but filing a PR is usually the better option. We can't help it here


----------



## fronclynne (Feb 14, 2010)

http://www.freebsd.org/cgi/query-pr.cgi?pr=143926

It may be the first PR I've ever filed, I hope I don't look like a complete Biden.


----------



## Seeker (Feb 15, 2010)

DutchDaemon said:
			
		

> Sure, but there you chose to run -STABLE as a relative newbie, which is contrary to common sense. You'll need quite a lot of dexterity to notice, handle and solve errors on a -STABLE platform ...



Exactly this explanation, was what I thought CURRENT branch defines.
I believed that STABLE is completely normal to be used for desktop etc..., as code is thorougly tested and just waiting to be put into "server grade" branch, that is RELEASE.
Gosh! Then I can't even imagine what happens under CURRENT.
Hell, I don't even wana now!


----------



## phoenix (Feb 15, 2010)

-CURRENT is the active development branch.  There are no guarantees that it will compile, install, or run, at any specific time.  The devs try to make it usable, but there are no guarantees.  User beware, and be prepared to roll-back, restore from backups, etc.  -CURRENT will eventually become the next X.0 release.

-STABLE is also a development branch, but with more stringent requirements on the usability, compilability, etc.  It's not guaranteed to work at all times, but should be usable by alert users.  Be prepared to troubleshoot, though.  -STABLE will eventually become the next X.Y release (where X is one of the currently supported major branches: 6, 7, or 8).

"Normal" users should stick to -RELEASE, and use the security branch for that release (RELENG_X_Y in cvsup terms) or freebsd-update.

IOW, using -STABLE or -CURRENT is at your own risk.


----------



## Seeker (Feb 15, 2010)

Thank you.
Just to say that STABLE worked for me, for 3 months, in which period I recompiled STABLE from src., each 2 weeks.
Third month... all hells break loose! 
So now I stick to RELEASE.


----------

