hi sacha, val,
On Monday 02 December 2002 04:44 pm, Sacha Chua wrote:
> This is a result of the file being marked as immutable (chattr +i
> /var/log/messages). You can remove the immutable flag with chattr -i
> /var/log/messages
regarding your reply:
i cannot think of a situation where /var/log/messages being immutable
would be useful. well, except one, i guess, where we set it immutable
so that it can't grow, but then ln -s /var/log/messages /dev/null works
for that too, and it works better since whatever is logging won't
get "write failed" errors.
is there some other scenario where /var/log/messages would be immutable
and it would be a good thing?
regarding val's original problem:
[something that might help]
i *have* had problems before where i could not delete files even
though "ls" showed them (and the permissions were good).
those were due to the box having been turned off without
shutting down (power plug removed for some reason, or
suspend failed and i had to turn the notebook off and on).
i guess ext3 (where /var/log is) and reiser (where i have /home)
sometimes barf when restoring the journal. it's as if the directory
entries were there but didn't point at the right inodes or something.
so when i'd try to delete the files i couldn't.
going to single user mode and doing an fsck would fix most
problems.
on the other hand, the original question had to do with identifying
where the original file is after an ln (i don't know why that would be,
there's not really any good reason to do a hard link for /var/log/messages
either, although i often do symbolic links (ln -s) when, for instance,
i decided on partition sizes wrong when setting things up and now
i want to have the logs on /usr/var/log but i still need links to them
in /var/log so that stuff that logs to there still works.
i suppose he didn't mean an ln -s since an ls -l would show where
the real file is. so i guess he means a hard link. is there a
meaningful answer to this question? or is the question not
meaningful? what i mean is, does linux (or, in general, unix) even
keep track of the concept of a file's [not the filename, the actual
data on disk organized as one logical unit] original filename?
i get the impression that for hard links (i.e., no -s param to ln), there
is no concept of an "original" filename . the file (on disk, so the physical
data, not the "name") will get physically deleted when the last hard link to
the file is deleted. i may be very wrong here though. if someone knows
i am, i'd be glad to be corrected.
is there some program in linux (or unix, generally) that will list all
the filenames that are linked to the same file? the best i can find for now
is: get the inode of one of the hard links (with a little program that calls
stat and prints the inode), then:
find -inum <inodenumber>
tiger
--
Gerald Timothy Quimpo tiger*quimpo*org gquimpo*sni-inc.com tiger*sni*ph
Public Key: "gpg --keyserver pgp.mit.edu --recv-keys 672F4C78"
Veritas liberabit vos.
Inigo Montoya: You seem a decent fellow, I hate to kill you.
Westley: You seem a decent fellow, I hate to die.
_
Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph
To leave: send "unsubscribe" in the body to [EMAIL PROTECTED]
Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph
To subscribe to the Linux Newbies' List: send "subscribe" in the body to
[EMAIL PROTECTED]
