Fedora Core 3 Directories

[redukt]

I'm no master at linux by any means, but I have a feeling that my base directory structure is overly complicated, especially considering that a lot of the directories are empty.

I'm running Fedora Core 3, and here's an 'ls' of '/':


bin boot dev etc home initrd lib lost+found media misc mnt opt proc root sbin selinux srv sys tmp usr var

Pretty sure lost+found is safe to delete.
Not sure about opt. The directory is empty.
Not sure about misc. The directory is empty.
Not sure about selinux. selinux was an option when I installed FC3, but it is disabled. I imagine that folder is safe to delete. The directory is empty.
Not sure about srv. The directory is empty.


I've seen a lot of distros before, but these directories are news to me!

:bang:

Any help would be awesome. It's not life or death, and if nobody is sure, I can always hit up a Fedora Forum later, as I have some questions about ACPI too.

TIA!
:cheers:

[Bok]

lost&found should remain, it is a linux directory where files with lost inodes etc get placed. For the most part it will be empty though.

/opt is probably not going to get used, I used to use it for Oracle installs on solaris
/misc - don't know why it's there.
ditto with /selinux and /srv

Make sure they aren't mounted filesystems.

what does

df -k

bring back ?

Bok

[redukt]

They're not listed in 'df -k' or even mentioned in /etc/fstab.

I'm at a loss!

EDIT: I'm too specific when I search for stuff sometimes. All I needed was to Google 'linux directories' and look around for a minute and I got the answer to a bunch of my questions. Well, I know what they ARE, but are they safe to delete with my system setup is the question :confused:

[rshepard]

Personally, I'd just leave them all in place. If they're empty, they're not hurting you as far as drive space. Also, Fedora may expect them to be there when you go to update the system.

[redukt]

Originally posted by rshepard
Personally, I'd just leave them all in place. If they're empty, they're not hurting you as far as drive space. Also, Fedora may expect them to be there when you go to update the system.

My desk is only functional is a place for stuff to be stacked on other stuff, not such much as a desk. Even my printer tray serves as a temporary filing cabinet.

My filesystem hierarchies? Clean as a whistle. I'm WAY anal about naming conventions and directory structures.

Like I said, its not something terrible, just irksome :swear:

[rsbriggs]

Just consider lost+found as being a system file that indicates that the current directory is a file-system mount point. It is generally created with a very specific inode number (11).

It is used by the fsck tool in the case of a disk or a mounted file system suffering an IO error or corrupt disk block, and in any case where a file name has been lost due to some sort of such corruption.

Don't rename it and don't delete it. It is SUPPOSED to be there.

As far as the other directories go, the different directories have various specific uses, and that is a very normal-seeming Red Hat / (root) directory layout, not particularly complicated.

"selinux" is part of the Red Hat secure linux implementation. You may or may not break your system by renaming or removing it. Various programs (that you may or may not ever install) will want to use or install themselves in "opt".

I don't see any particular reason to delete or re-name anything there. Since you are acting as the system administrator of your own system your mantra should be to operate with a very "light hand" on files, especially system files, that you are not familiar with. You should become very familar with the Red Hat File System Standard (FSSTND) before touching anything in the root directory....

For the very same reasons, you wouldn't want to go into the c:\ directory of a WinDoze system, unhide all the files there, and start deleting or re-naming them....

[redukt]

Originally posted by rsbriggs
Don't rename it and don't delete it. It is SUPPOSED to be there.

For some reason I always thought these directories were only created after a filesystem error had already occured or a device wasn't cleanly unmounted. Thank you for the clarification :)


For the very same reasons, you wouldn't want to go into the c:\ directory of a WinDoze system, unhide all the files there, and start deleting or re-naming them....

I'm actually very cautious, I just get overzealous sometimes. Luckily, this was not one of those times :D

I've been toying with various flavors of *nix on and off for years now, and I can survive, but I'm still in a stage where if I actually sit down and do more than just run the same few apps and check the same few logs day in and day out, then I will learn something new every single time.

Thank you all for all your help! Believe it or not, I'm not a total n00b! :blush:

[rsbriggs]

They're not (only) created after an error, they're initially created at the time you use a command like "mke2fs" to generate a file system on a device.

You can delete lost+found files, but it is better to just leave them alone. If you do leave them alone, you'll be able to use their presence (or absence) as an indication of whether a directory is a mount-point or not.

Let's say, for example, that you cd into some random directory (using Solaris as an example here) - oh, say, "/export/home".

If a lost+found file exists there, you know without having to look any further that this is a separate device and file system that is mounted here. If it isn't present, you could assume that "home" is simply a sub-directory that was created under "/export".

On a small home system, you might set things up so you only use a single partition for / and everything on down from there. In that case you'd only have one lost+found file in /

On larger systems, it is possible that /opt, /var, /home, /tmp and possibly many other directories are mounted on separate devices/file systems (so you expect to see lost+found in those directories.) You'd be alerted instantly that something odd is going on with the file system - possibly someone screwed something up in /etc/fstab - if you don't see the file in those places when you make your administrative rounds...