Re: Please /dev/null html-only mail rather than sending it out on this list
I suspect this is the more general problem that SpamAssassin on Namesys needs to be updated, since a *lot* is getting through now. Most servers get patches to fix security holes. SpamAssassin gets patches to spam holes. Both are annoying. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \ (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_ \ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
From: Hans Reiser [EMAIL PROTECTED] these problems will not exist significantly in reality. Look at netapps and snapshots and clearcase and other filesystems, I remember wondering if .snapshot could be a problem when netapps were new and it was never a problem. Notice though that that filename begins with ., not a letter. This causes all programs to treat it specially. Also note that that filename is nine characters long, and therefore making a purely random collision less likely by more than four orders of magnitude. People who find it is a problem can #define it to something else. If 5 people bother to do so, I will be surprised. Many languages have reserved keywords. I REJECT THIS! I believe Ada is almost the only programming language without reserved words. The thing is a filesystem is NOT a programming language! It is designed to handle files with arbitrary names, no matter how odd. Only programmers deal with C, end users must deal with filesystem limitations. From: cami [EMAIL PROTECTED] Not sure if anyone has bothered to check if this would impose the limitation that people are worried about. From a quick glance, none of the linux distro's have ever had a file / directory called metas before. `metas` isn't even a real a word anyway (at least not an english word) so the chances of it being a big issue are very very small.. freshmeat.net's search shows not even one hit for the word metas and that pretty much the majority of linux/coding related projects.. Good point, search engines as evidence. The problem is you're only looking at distributions, which are going to be highly similar and you're completely missing end users. So let us take this to a full search engine and see what turns up... Hmm, roughly a million hits, let us look at a few samples: http://www.metas.ch/ http://vancouver-webpages.com/META/mk-metas.html http://www.metas.com.br/ http://metas.enfermeria21.com/ http://www.metas.com.mx/ Okay, out of one million hits, we randomly look at ten, and half feature metas in the URL somewhere. Going the other direction, Google indexes roughly 4 billion pages. If we guess the above search was representative, roughly 500,000 pages will include metas somewhere in the URL, possibly only as a hostname, but somewhere. So we've managed to collect 1 out of every 10,000 pages that Google indexes. Though we don't have a direct proof, I hope I've come close enough to scare you. Hans, what will it take for you to change your mind? -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \ (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_ \ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
Re: [PATCH] metas in reiserfs v4 snapshot 2004.03.26
From: Narcoleptic Electron [EMAIL PROTECTED] Hubert Chan wrote: That effectively kills all filenames that contain @, much worse than just a metas conflict IMHO. I strongly agree: - A restricted character in all names is far more likely to impact users than a single restricted name. This is why a couple candidates need to be brought up. Some seem good at first glance, but are really bad choice after a bit of thought. So you're right a badly chosen single character will be really bad. A good choice needs to have minimal impact by being pretty much unused in filenames. A corollary is that a badly chosen directory name will have a horrific impact on users just as much as a badly chosen special character. I think that the meta directory needs to be thought of not as a special directory, but as a normal directory that has a name that is interpreted in a special way by the system. In other words it is special, but it isn't special? You can't have it both ways. metas is a perfectly valid filename on all other filesystems. It is a valid word or partial word in several languages, bad choice. Files/directories begining with . are at least already handled specially by all tools. Names that are valid words are precious, like gold you shouldn't steal them. There is also the problem that things like Apache deliberately filter out access to some files (like ..) because they're magic. By adding another magic filename you've made those harder, at least begining it with . will keep those tools' job easier (and you don't introduce a huge security hole by adding a filesystem). Also I feel it should be on the file itself. ie for the file /tmp/fooblah you should be able to access the file's metadata by open()ing/using readdir() on /tmp/fooblah/metas or (/tmp/fooblah/..metas or whatever). No one in this thread has commented on + as the default meta directory name (one of the final contenders in our previous thread on the subject). Again, the reasons: - Short (one character) - Makes sense in all languages (meaning additional information) - Available on all int'l keyboards Bad choice. Note the lost+found directory found on *all* Unix filesystems. If we need one more option | might be viable. Also, a question: are all meta files necessarily pseudo files? Should users be able to put regular files in there to be interpreted as pseudo files? This will help to clarify some things for me. My impression is, that the metadata appears as normal files and is accessible as normal files. Just gets interpreted in an interesting way. I doubt metadata would have an owner or permissions separate from the file/directory though. I imagine this is similar to Apple MacOS 10, where all files have a mime-type that is accessible as filename/mime-type. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \ (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_ \ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
Re: [reiserfs-list] copying partition to partition, sector by sector, live
From: Phil Howard [EMAIL PROTECTED] On Mon, Apr 22, 2002 at 02:58:34PM -0400, Chris Mason wrote: | Doing it safely will require something like lvm or evms snapshots. You | could do the sector by sector copy and then run reiserfsck | --rebuild-tree. The latest versions of reiserfsprogs are faster, the | speed relative to a search for updated files will depend on your data | set. | | More importantly you just don't get a consistent copy, regardless of the | FS you choose. I wouldn't consider a sector by sector copy on a mounted | FS a valid backup of any type of filesystem, especially not a tree based | one. But I'm starting to think that with reiserfs, I need to go back to rsync as the backup mechanism. Some memory leak and stalling problems with rsync seem to be fixed, now. More significantly there was a security problem fixed in January. -- |\__/|\__/|\__ --= 8-) EHM =-- __/|\__/|\__/| \|| | [EMAIL PROTECTED] PGP 8881EF59 | ||/ \ \ | __| -O #include stddisclaimer.h O- |__ | / / \___\_|/82 04 A1 3C C7 B1 37 2A E3 6E 84 DA 97 4C 40 E6\|_/___/
Re: [reiserfs-list] Silly question, defrag
From: [EMAIL PROTECTED] snip I have to wonder about your motives here, Hans. You are the one who stands to gain by capitalizing on newbie Unix/Linux users misunderstanding of filesystems based on their experience with DOS and Windows and here you are promoting defrag as a feature which puts your FS above others. They have learned to compulsively defrag their disks once a week and you are looking to feed their addiction. I think reiserfs is really great and a defrag/repacker will be nice but the above strikes me as a bit strange. How long has ext2 been around as the stock Linux filesystem? More than long enough for people to have realized whether a defragger would be useful. Yet I can't think of a single distribution (of Linux or Unix in general) that comes with a defragger. Stephen Tweedie wrote one for it but nobody bothers to use it or even to include it with their distro. This leaves the the only option to defrag once the file has been completed OR at some user defined interval. Some fs may try to reduce the incidence of this but cant prevent it happening. True. Some of the measures that are taken can be quite effective. Reserving 10% overhead which only root is allowed to write in is extremely effective with SunOS's flavor of UFS. Currently the only way to defrag an ext2 fs (or reiserfs) is a copy off, mke2fs and copy back cycle - hardly ideal. BTW if you are interested in scripts that capable of totally framenting an ext2 partition (as reported by chke2fs and demonstrated by timing a grep) and also a discussion of the problem - check the archives. Not true, there is a e2defrag out there. Now, e2defrag will defragment a filesystem, however the problem is that it greatly promotes future fragmentation (got to maybe 2% fragmentation after months of use, but within a week of running e2defrag it hit 8% fragmentation). I must theorize that it packs files tightly rather than using the headroom leading to the effect seen. -- |\__/|\__/|\__ --= 8-) EHM =-- __/|\__/|\__/| \|| | [EMAIL PROTECTED] PGP 8881EF59 | ||/ \ \ | __| -O #include stddisclaimer.h O- |__ | / / \___\_|/82 04 A1 3C C7 B1 37 2A E3 6E 84 DA 97 4C 40 E6\|_/___/
Re: [reiserfs-list] correct version of reiserfs for 2.2.17
From: Adrian Phillips [EMAIL PROTECTED] Cassandra == Cassandra Sewell [EMAIL PROTECTED] writes: Cassandra I have taken over support for a machine running the Cassandra 2.2.17 kernel with reiserfs 3.5.32 . We cannot upgrade Cassandra to a later kernel at this time. I would like to know Cassandra if this is the correct latest version of reiserfs Cassandra that can be run with the 2.2.17 kernel. If this is not Cassandra the correct reiser, which version should we be running Cassandra on our machines. Also, is there any type of change Cassandra listing that shows what fixes, etc are in the different Cassandra reiserfs versions? I don't understand why you cannot upgrade. 2.2.20 with 3.5.34 is a better bet than 2.2.17 and 3.5.32 as far as my own experience is concerned. There is a much stronger reason to use 2.2.20, than it merely works better. There were two security holes involving ptrace in 2.2.17. These are fixed in 2.2.20. These allow a non-root user to gain root access. -- |\__/|\__/|\__ --= 8-) EHM =-- __/|\__/|\__/| \|| | [EMAIL PROTECTED] PGP 8881EF59 | ||/ \ \ | __| -O #include stddisclaimer.h O- |__ | / / \___\_|/82 04 A1 3C C7 B1 37 2A E3 6E 84 DA 97 4C 40 E6\|_/___/
Re: [reiserfs-list] magic is useless Determining File Types
From: Hans Reiser [EMAIL PROTECTED] Jens Benecke wrote: User space: There should be a way of specifying what default MIME type a file should get and whether the MIME type should follow the extension (if it has one). One thing I didn't like in OS/2 was that sometimes it was really difficult to persuade the WPS to open a specific file with another viewer by default (eg. hex viewer). Changing the extension didn't help and the EAs weren't editable without extra tools. I think this is the most important thing, that one should be able to cast a file into a different type. Then one also needs to be able to convince app writers to try to make their apps work on the most generic type possible, which is difficult to do but probably we will have to endure failure at this in return for the benefits of typing and the object orientation it allows. I think that at this point we just need to focus on completing version 4, and it is good to know that people will use its features once they are available. We are indeed going to give you the flexibility you need to create whatever file/attributes or file/forks you need, though we will make do this by making files and directories able to do what you want attributes and resource forks able to do (this is nontrivial). Yes, once everybody supports it, it will no longer be an issue, however what should you get when you open the various resources? You need to be able to get *everything* for programs such as tar and cp, but then you've got ordinary programs that just want their data. My tendancy is that the prior suggestion of the structured file is the way to go. Open file and you get *everything*, open file/data and you get only the data. ..content-type turns out to be something that needs no specific support in version 4, the generic mechanisms will be enough for it. Suggestions for alternatives to .. as the style convention for meta-data about an object are welcome. May I suggest // instead? This is much better for a couple reasons. First / by itself is already a magic character, and so this doesn't annoy people by stopping them from creating files with certain names; same for programs. Second this is usable on directories, ie a file bar inside a directory foo (foo/bar) is distinct from an attribute bar on the directory (foo//bar). There is an issue of going completly overboard, attribute/subattribute/subsubattribute anybody? This is certainly an overall interesting idea. How about file//acl for accessing ACLs? This does mean though you *MUST* have a filesystem specific dump tool. -- |\__/|\__/|\__ --= 8-) EHM =-- __/|\__/|\__/| \|| | [EMAIL PROTECTED] PGP 8881EF59 | ||/ \ \ | __| -O #include stddisclaimer.h O- |__ | / / \___\_|/82 04 A1 3C C7 B1 37 2A E3 6E 84 DA 97 4C 40 E6\|_/___/
