symlink at 8-RELEASE

Seeker

Seeker

Code: 
# 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.
Click to expand...
That is really strange as I actually get file chmod-ed
Code: 
# 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)
Click to expand...
Code: 
# lchmod 0777 SLINK
lchmod: Command not found.
This is a total mess!
 
I can not reproduce your problem:

Code: 
% 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
 
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.
Click to expand...
?

From chmod(1)
Code: 
     -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.
 
knarf said:
I can not reproduce your problem:
Code: 
% 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

Bye,
Knarf
Click to expand...
You DID reproduced my problem :P
By chmod-ing LINK, you actually edited FILE, not a link.
fronclynne said:
Where did you read ?
Click to expand...
You don't wana know! FreeBSD's official FAQ! :P
 
Seeker said:
You DID reproduced my problem :P
By chmod-ing LINK, you actually edited FILE, not a link.
Click to expand...

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
 
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
 
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.
 
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.
Click to expand...
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.
:P
 
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.
 
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!
 
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.
 
Of course, but filing a PR is usually the better option. We can't help it here ;)
 
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 ...
Click to expand...

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! :P
 
-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. ;)
 
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! :P
So now I stick to RELEASE.
 
You must log in or register to reply here.
Back
Top