The permissions, owner, and group of a symlink are not significant. They are there only because other files have them and symlinks were fitted into the existing framework of being a file. A symlink i
GNU is implementing previously existing behavior. Symbolic links originated in BSD. It is a BSD feature that migrated to System V and then to GNU and elsewhere. The behavior is now standardized by PO
Just to tie the archive together, here is a previous discussion: http://lists.gnu.org/archive/html/bug-fileutils/2003-10/msg00000.html Ah, I see. I was confusing Jim's the -n suggestion with your not
Thank you for you bug report. But unfortunately no script was attached to your message. Please follow up to the mailing list again with the commands needed to reproduce the problem. Including your co
This has appeared as a portability problem a number of times in the past. If there is any possibility of having a symlink to a directory then the only portable solution is to remove symlinks before c
I have mixed thoughts about subscribing GNU's bug-coreutils to the Debian coreutils BTS list. There are good points and bad points and I can think of several of each. It will be more information and
tag 13742 + moreinfo notabug close 13742 thanks Please do not worry. But there are questions. What is the "ll" command? And alias for "ls -l"? Or an alias for "ls -lF"? Or something different? What i
Okay so far. Okay. This will create a symlink ./this/a with a value of "a". That is almost certainly not what you want to do. Right. In the "./this" directory the "./a" symlink points to "a" making i
severity 10311 wishlist thanks There are several important points concerning symlinks, the mode bits, chmod(1) and chmod(2). * The mode bits of a symlink are not used. The original Unix authors ignor