acl = access control lists = permissions like in ntfs = joe has rwx, mam has rwx ... on same file or dir

Mine is at the default 20 reboots or 180 days, I guess it will run fsck every reboot if you don't reboot but every 180 days.


You could turn that feature off, but it's a good idea to allow it to be sure your data is ok

Still weird. I reboot almost every day, and it still used to do it on every reboot. I think it was a SuSE issue with Ext3 and I think SuSE defaults to a fsck on every boot.

heh, no, still won't swallow it shashshshashahsouneheu .. keep clutching at straws!

hehe Acid, I won't clutch at straws No need to with SuSe and Reiser.
SuSE + Reiser = Almost paradise

lol, kidding

http://www.namesys.com/

http://www.nondot.org/~sabre/os/articles/FileSystems/

Suse default is normally fsck every 20 boots. That might be set wrong - you can set that to anything you want.

yes you can do any of the settings with tune2fs

-c 20 is the default, also there's usually an -i option set for minimum interval in days.

if you do tun2fs where it would write down checking interval? In /etc/fstab ? or to fs somewhere?

no it's not in fstab


Maybe it's in the .journal file, not really sure. I just know it works.

I know it works, but was wondering where is it

It has to be in the file system because each drive is different and the info is used when it's mounted. I doubt if it's an actual file you can edit or even read

U R probably right

try tune2fs -l /dev/hda

Has anyone heard about the reiserFS vulnerability to long filenames. I think I might be suffering from it. I use reiser under Mandrake 8.2. In the user account I use most frequently, the Konqueror browser became unstable and started causing system reboots. I isolated the problem to the kio_http cache under the .kde directory. I moved it to the .Trash directory, but can't delete three directories,...

kio_http/cache/c
kio_http/cache/h
&
kio_http/cache/o

I can inspect the contents of /c and /o but can't even inspect the contents of /h save the system locks up or crashes. My system runs snort, so I'd figure that it would have detected if there was an attempt at intrusion,... but I still can't get rid of these directories and the 1-2 KB files within them....

I've tried doing it in root, as the user, using superuser file tools and terminals, logged in as root under a runlevel 3, everything,... no dice.

Anyone have any ideas???