Renaming lost+found

If this is ext2 specific, just say so and I'll find a better list to discuss
this: (any good ext2 lists available for example?)

Is there a way to rename lost+found ?? It bothers me to see it in ls all the time because 99.9% of my time it's just useless and I really think .lost+found (a hidden file) would make much more sense for daily use. I assume this would require some ext2 changes as well as a patch to e2fsck etc. (with backwards compatibility of course)

Regards,

Rob

Rob Kaper | [email protected] [email protected] [email protected]
          | http://capsi.com/ - telnet://chat.capsi.com:2300/
          | 'What? In riddles?' said Gandalf. 'No! For I was talking aloud
          | to myself. A habit of the old: they choose the wisest person
          | present to speak to; the long explanations needed by the young
          | are wearying.' - "Lord of the Rings", JRR Tolkien
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Get used to it. This is part of the Linux/Unix heritage! A file-system without a lost+found directory is like love without sex.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

You mean, possible but leaving you unsatisfied? Well, I think a file system without a lost+found is a lot worse.

Thunder
---
Woah... I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard god...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Followup to:  <[email protected]>
By author:    Thunder from the hill <[email protected]>
In newsgroup: linux.dev.kernel

Hello people... the original question was: can lost+found be *renamed*, i.e. does the tools (e2fsck &c) use "/lost+found" by name, or by inode? As far as I know it always uses the same inode number (11), but I don't know if that is anywhere enforced.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I seem to recall e2fsck complaining when I renamed lost+found, but that may well be a consistency check. Don't quote me on this, though.

Mo.

- --
Mo McKinlay
[email protected]
- ------------------------------------------------------------------------- GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjp0kgYACgkQRcGgB3aidfngIACdH4Ze9KRUS/jExERYM0Jt0n4e WyMAoKxzOr7KnVeEoHCHKlCBjNcncx8U
=myDq
-----END PGP SIGNATURE-----

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hello,

I was wondering what 802.11 PCI cards anyone knows of that run
under Linux-2.4. (or 2.2 for that matter)

I have looked at Documentation/Configure.help and done a quick
grep of all the documentation for "802.11" without much luck. I can't seem to find anything related to the aironet cards that are mentioned in ./Configure.help -- it would be a matter of guesswork for me to figure out which, if any, Cisco card is the same one that the kernel supports.

Does anyone know if anyone has released (working) drivers for
their 802.11 cards that have not been incorporated into the kernel?

I know D-Link has some 802.11 cards out right now, but I haven't
seen any mention of support for Linux. I know other D-Link devices are supported; does anyone know if someone is working on a driver for their card? If not, have they been receptive to requests for documentation?

Thanks!

Mike Pontillo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I _think_ a good many of the 802.11 wireless ISA and PCI cards are just bus to PCMCIA adapters, so it would be a question of whether or not the PCMCIA card is supported and if the bridge is supported.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Last I knew (straight from the Lucent people), the ISA bridge
card worked fine and the PCI card did NOT work at all. I've since confirmed that, first hand, myself (I currently have the ISA bridge in operation) on the 2.2 kernels. The ISA bridge also works on the 2.4 kernels but I have not retested the PCI bridge on 2.4. The Lucent people claim that the Linux pcmcia people are aware of the problem.

Mike

 Michael H. Warfield    |  (770) 985-6132   |  [email protected]
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

There is a rather informative discussion of wireless support at :

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.html

Though possibly a little out of date, the author of this obviously did their research. Kudos!

--
Joe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi,

I have a PCI -> PCMCIA bridge + lucent wavelan card working fine with the GPL driver (not the Lucent proprietory one) and 2.4. From memory all I had to do was stop pcmcia-cs from using the lower io port range (there must have been conflicts with existing devices).

#include port 0x100-0x4ff, port 0x800-0x8ff, port 0xc00-0xcff include port 0x800-0x8ff, port 0xc00-0xcff

Anton
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

m> The ISA bridge also works on the 2.4 kernels but I have not m> retested the PCI bridge on 2.4.

The Lucent PCI-to-Cardbus bridge only works on machines that have a recent PCI BIOS. Any motherboard more than about 16 months old simply won't find the bridge card, and hence neither will Linux.

	<b

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hmm, this is interesting... I know that the kernel can be set to
try to detect PCI devices on its own, without the help of the BIOS. Is there any reason why that feature wouldn't work with this particular type of card?

Thanks,
Mike Pontillo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

(pretty easy to find out:)

[root]:# fsck -f /test
Parallelizing fsck version 1.19 (13-Jul-2000) e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09 Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure
Pass 3: Checking directory connectivity /lost+found not found. Create<y>?

It created lost+found with inode 183 as 11 was used by renamed dir. No idea if it would have trouble salvaging a corrupt fs after this. (but logic says no it dare not)

-Mike

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Bzzt. /lost+found just happens to use inode 11 on 99.9% of filesystems because it is the first inode available when mke2fs is creating the filesystem. If you check <linux/ext2_fs.h>, it has:

#define EXT2_GOOD_OLD_FIRST_INO 11

It is perfectly acceptable to delete lost+found, and create it again with mklost+found, and chances are it will have a different inode... Just tested it, and sure enough, I got inode 612 for lost+found this time. I'm pretty sure that e2fsck looks for the name /lost+found, rather than inode 11.

This means that with stock e2fsck, mke2fs, mklost+found, you can't rename lost+found and expect anything to work. However, I would imagine it isn't _too_ hard to change these tools to create a different directory, and for e2fsck to look for the standard or the new directory to put nameless inodes.

Looking at the e2fsck source, there only appears to be a single instance of the string "lost+found", in e2fsck/pass3.c:get_lost_and_found():

	static const char name[] = "lost+found";

Same with misc/mke2fs.c:create_lost_and_found() and misc/mklost+found.

Cheers, Andreas

PS - don't blame me if you never find your files after a bad crash. At
least when it is called "lost+found" you occasionally have a look in there.

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

e2fsck uses /lost+found by name, not by inode. It will recreate a new lost+found directory if one doesn't exist. *However*, if the filesystem is badly corrupted, it's possible that when it allocates blocks for the lost+found directory, it might override a datablock that might possibly be recoverable if one were truly desparate and using a disk editor to search for keywords. (This would only happen if part of the inode table had gotten corrupted due to a hardware error --- i.e., such as the anecdotal evidence of DMA units that write garbage to the disk because during a power failure, where it is conjectured that the +5V power rail drops below the critical working of the memory faster than +12V power rail drops below the critical working volutage of the disk drive --- so that the record in the inode table that a certain disk block was in use is erased.)

So if you really dislike lost+found, go ahead and delete it. It removes a somewhat tiny safeguard, but being able to take advantage of it requires wizard-level skills (there are no tools to do this automatically, since it requires human intuition and a knowledge of what file you might be trying to save.) So it would probably only be used in the case of someone who had 10 year's of Ph.D. research that wasn't backed up, and this was the only way they could get the data back. And although not doing disk backups is grounds for general redicule, losing ten years of graduate research would probably be reguarded by most as cruel and unusual punishment. But if you're not in a Ph.D. program, it doesn't matter, yes? (And in any case, we ALL do backups, all the time, religiously and on a regular schedule, RIGHT? :-)

- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

FWIW IBM's JFS file system does not have a lost+found directory. I dont remember if reiserfs does or not.

Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

reiserfsck creates it.

-chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

You could also just delete it, but then you run into problems when e2fsck is run on a broken filesystem. Use ext3 instead. The lost+found dir is in many (most?) Unix filesystems, for use when things go bad.

You _could_ change it to be a hidden file, but then you would have to remember where it was after e2fsck moves half of your files into it after a crash. It probably wouldn't be too much work to change e2fsck. You also need to change mke2fs and mklost+found as well.

Cheers, Andreas

Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

An other maybe too obvious way, could be to :

alias ls='ls | grep -v "lost+found"'

if you are really annoyed by this tiny thing, which is IMHO, really the least thing i could be annoyed of...
This took part on Unix file system design, from the old days, as mentioned earlier by others. Also think, that you might be happy the day, it will be usefull... ;-)

Regards,

Patrick

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

alias ls="ls -I "lost+found"'

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I think JFS indeed doesn't have it. And ReiserFS doesn't too. This should be common place for journaling filesystems.

[]s

 Rodrigo Barbosa (morcego)         - rodrigob at conectiva.com.br
 Conectiva R&D Team                - http://distro.conectiva.com.br
 "Quis custodiet ipsos custodiet?" - http://www.conectiva.com

Hi,

No, it's nothing to do with journaling or not. Even journaling filesystems can suffer IO errors or corrupt disk blocks, and any case where you have a file whose name has been lost due to such corruption needs to be dealt with by the fsck tool. Traditionally, fsck puts such files into lost+found, and in the presence of data corruption, it will still need to do so even with a journaling filesystem.

ext3 uses lost+found in exactly the same way as ext2 for this reason.

Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/