jik@athena.mit.edu (Jonathan I. Kamens) (05/04/89)
It it safe to assume when writing a program which manipulates directories that . and .. will always be the first two entries in a directory? If I can't assume that, then I've got to compare every file in the directory to "." and "..", and this would probably slow the program down even more than it already is. As it is now, I'm just doing readdir(dirp); readdir(dirp); /* get rid of . and .. */ in my code right after the opendir(). Is this valid? Jonathan Kamens USnail: MIT Project Athena 410 Memorial Drive, No. 223F jik@Athena.MIT.EDU Cambridge, MA 02139-4318 Office: 617-253-4261 Home: 617-225-8218
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/04/89)
In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes:
-It it safe to assume when writing a program which manipulates
-directories that . and .. will always be the first two entries in a
-directory?
No, they're not present in some remote filesystem directories.kemnitz@mitisft.Convergent.COM (Gregory Kemnitz) (05/05/89)
In article <11108@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > > It it safe to assume when writing a program which manipulates > directories that . and .. will always be the first two entries in a > directory? > > If I can't assume that, then I've got to compare every file in the > directory to "." and "..", and this would probably slow the program > down even more than it already is. > After checks on our file system, I found that this assumption is PROBABLY correct. However, this type of thing is EXTREMELY DANGEROUS, unless it is part of the definition of the directory structure (It might well be - if it is ignore this message and I'll be eating flames). This type of assumption usually leades to unportable code. (will your code run on UNIX forever??) A portable way to implement this assumption (without error checking for clarity): struct dirent (direct??) *dir1, *dir2; BOOLEAN dot_and_dotdot_read; dir1 = readdir(dirp); dir2 = readdir(dirp); dot_and_dotdot_read = (!strcmp(dir1->file_name, ".") && !strcmp(dir2->file_name, "..")) || (!strcmp(dir1->file_name, "..") && !strcmp(dir2->file_name, "."); if (dot_and_dotdot_read) { proceed using assumption... } else { proceed carefully. Remember to process dir1 and dir2 } I may be wrong about the members of the structures, but you get the point. Also, I omitted error checking. In any code of this type, you should always check the return value. Greg Kemnitz
conan@vax1.acs.udel.EDU (Robert B Carroll) (05/05/89)
In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: > >It it safe to assume when writing a program which manipulates >directories that . and .. will always be the first two entries in a >directory? > NO, its not save to assume that. try "touch #abcd" then 'list' the directory. -- conan@vax1.acs.udel.edu CONAN THE BARBARIAN
trebor@biar.UUCP (Robert J Woodhead) (05/05/89)
In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >It it safe to assume when writing a program which manipulates >directories that . and .. will always be the first two entries in a >directory? No. It isn't safe to make this assumption. Even if it is true on your machine, it may not be on another implementation (it isn't on my Xenix box, according to a quick test using ``l''), and it surely will be changed _just_to_smite_your_program_ at some time in the future. The only safe assumption to make when writing a program is that _everything_ and _everybody_ is out to get you. Variables won't; Constant's aren't; and Users like nothing more than to sadistically abuse your program. -- Robert J Woodhead, Biar Games, Inc. !uunet!biar!trebor | trebor@biar.UUCP "The lamb will lie down with the lion, but the lamb won't get much sleep." -- Woody Allen.
panos@boulder.Colorado.EDU (Panos Tsirigotis) (05/05/89)
In article <672@mitisft.Convergent.COM> kemnitz@mitisft.Convergent.COM (Gregory Kemnitz) writes: >In article <11108@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: >> >> It it safe to assume when writing a program which manipulates >> directories that . and .. will always be the first two entries in a >> directory? >> >> If I can't assume that, then I've got to compare every file in the >> directory to "." and "..", and this would probably slow the program >> down even more than it already is. >> > >After checks on our file system, I found that this assumption is PROBABLY >correct. However, this type of thing is EXTREMELY DANGEROUS, unless it is >part of the definition of the directory structure (It might well be - if it >is ignore this message and I'll be eating flames). This type of assumption >usually leades to unportable code. (will your code run on UNIX forever??) >... Copying from dir(5) of the BSD programmer's manual: -> By convention, the first two entries in each directory are -> for `.' and `..'. So, as long as the file system is maintained by UNIX it is safe to assume that the first 2 entries are for for "." and ".." (I assume that System V follows the same convention; I don't have those manuals available). Panos Tsirigotis ---------------------------------------------------- | Email address: panos@boulder.colorado.edu | ----------------------------------------------------
bph@buengc.BU.EDU (Blair P. Houghton) (05/05/89)
In article <3540@udccvax1.acs.udel.EDU> conan@vax1.acs.udel.EDU (Robert B Carroll) writes: >In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >>It it safe to assume when writing a program which manipulates >>directories that . and .. will always be the first two entries in a >>directory? > >NO, its not save to assume that. >try "touch #abcd" then 'list' the directory. To beat this horse quite dead, any leading character that would sort before the period will place the filename before the . and .. in a directory listing. The ascii characters that will do this are space, !, ", #, $, %, &, ', (, ), *, +, ,, and -. I haven't tried it, but I bet you can get the nonprinting ascii characters to do it too. There are 32 of those. I've actually had the fun ( yeah, right %-) ) task of trying to remove a file called * from a directory. It's easy, _once_you_know_how_... --Blair "...and now, with this set of Time/Life books..."
nichols@cbnewsc.ATT.COM (robert.k.nichols) (05/05/89)
In article <2778@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: ... >To beat this horse quite dead, any leading character that would sort before >the period will place the filename before the . and .. in a directory >listing. ... Sorry, but the horse is still very much alive. Directory listing programs such as "ls" will, by default, list directory entries in alphanumeric order, which is NOT the same as the order in which the entries actually appear in the directory. If you want to see the actual order, use "ls -f" which skips the sorting and shows the entries in the order they actually appear (and will be found by readdir() or its equivalent). >I've actually had the fun ( yeah, right %-) ) task of trying to remove a >file called * from a directory. It's easy, _once_you_know_how_... Isn't it fortunate that "rm" doesn't try to do the filename expansion for itself?! -- .sig included a no extra charge. | Disclaimer: My mind is my own. Cute quotes and batteries sold separately. | >> Bob Nichols nichols@iexist.att.com << |
mchinni@pica.army.mil (Michael J. Chinni, SMCAR-CCS-E) (05/05/89)
> From: "Jonathan I. Kamens" <jik@athena.mit.edu> > Subject: Dot files always first in directory? > Date: 4 May 89 13:31:57 GMT > To: unix-wizards@sem.brl.mil > > It it safe to assume when writing a program which manipulates > directories that . and .. will always be the first two entries in a > directory? On our systems (DoD Army) we have a program which uses several files that begin with a "," for storage. These all apear before "." and ".." in the directory listings. Therefore, I would say that you cannot make you assumption. Also, users sometimes create files (by accident) that may begin with some of the following characters, all of which would apear before "." and "..": ! " # $ % & ' ( ) * + , - /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Michael J. Chinni Chief Scientist, Simulation Techniques and Workplace Automation Team US Army Armament Research, Development, and Engineering Center User to skeleton sitting at cobweb () Picatinny Arsenal, New Jersey and dust covered terminal and desk () ARPA: mchinni@pica.army.mil "System been down long?" () UUCP: ...!uunet!pica.army.mil!mchinni /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
ekrell@hector.UUCP (Eduardo Krell) (05/05/89)
In article <2778@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >To beat this horse quite dead, any leading character that would sort before >the period will place the filename before the . and .. in a directory >listing. That's because "ls" sorts the directory entries by default. The original question was about readdir() which doesn't. Use "od" or write a small program using opendir() and readdir() and you'll see that "." and ".." are the first and second entries. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com
consult@osiris.UUCP (Unix Consultation Mailbox ) (05/05/89)
In article <2778@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >In article <3540@udccvax1.acs.udel.EDU> conan@vax1.acs.udel.EDU (Robert B Carroll) writes: >>NO, its not save to assume that. >>try "touch #abcd" then 'list' the directory. > >To beat this horse quite dead, any leading character that would sort before >the period will place the filename before the . and .. in a directory >listing. That ain't no horse, it's a red herring. The order of files in a "directory listing" (using ls, which by default sorts everything by ASCII collating sequence before writing it to stdout) has nothing to do with the real order of the files in the directory. You can only force that order by writing the directory yourself, which is something permitted only to root and not recommended anyway. phil
tale@pawl.rpi.edu (David C Lawrence) (05/05/89)
In <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: jik>It it safe to assume when writing a program which manipulates jik>directories that . and .. will always be the first two entries in a jik>directory? In article <2778@buengc.BU.EDU> bph@buengc.BU.EDU (Blair P. Houghton) writes: bph> To beat this horse quite dead, any leading character that would bph> sort before the period will place the filename before the . and bph> .. in a directory listing. The ascii characters that will do bph> this are space, !, ", #, $, %, &, ', (, ), *, +, ,, and -. I bph> haven't tried it, but I bet you can get the nonprinting ascii bph> characters to do it too. There are 32 of those. Now here is where it really matters: are you using a script or C to get at the directory. Jonathan showed, in either the original posting or in a follow-up, that he wanted an example in C. Even in the script, it is only the default output of ls(1) that will sort names the way you offer; ls -f will give them the way they are arranged in the block. #.newsrc# currently is the last thing listed in my home directory by an ls -f. With Sun machines, . and .. are stated as being the first two entries in a directory block "by convention". In fact, fsck will complain if it comes across a d block which first two inodes do not point to itself and to its parent respectively (exception being the root directory whose parent does not exist; .. == .). I suspect that if Jonathan is writing for multiple architectures for Athena then he should check the manuals for different machines he knows he will have to support, just to be sure. -- tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.edu
heather@maui.cs.ucla.edu (Heather Burris) (05/05/89)
In article <535@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes: >In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >>It it safe to assume when writing a program which manipulates >>directories that . and .. will always be the first two entries in a >>directory? > >No. It isn't safe to make this assumption. Even if it is true on your >machine, it may not be on another implementation (it isn't on my Xenix >box, according to a quick test using ``l''), and it surely will be changed >_just_to_smite_your_program_ at some time in the future. This and other answers about why it isn't safe to assume that . and .. are first in the directory are correct, but they are correct for the wrong reasons. There are two reasons that I can think of for why it is not safe to assume that . and .. are first: 1) The basic reason, true on all UNIX systems that I know of, is that . and .. are links and because of file system damage they could be removed. Therefore it is not safe to skip the first two directory entries blindly. 2) The second reason is portability. On current BSD systems, mkdir is a system call and is an atomic operation and therefore assuming that . and .. are always present and always first is pretty safe. However, on older UNIX systems, a mkdir is done by using mknod() and then linking in . and .. to the new directory; 3 seperate system calls. If the mkdir command were to be interrupted by a system crash, . and .. would not get linked in. Not all fsck's check for . and .. so a directory can be missing these permanently. Also, to patch up a damaged filesystem, the super user can manually link in . and/or .. and then these entries would get whereever there is an open spot in the directory and not necessarily at the beginning. The reasons given about using ls to check what could come before . and .. (and giving examples of characters that would come before . in the ASCII sorting sequence) are bogus, because ls sorts the directory before printing it. If you want to see the "real" order of directory entries, i.e. the order that readdir() will present, use the command: od -c <directory name> Heather Burris, UCLA
ghe@nucthy.physics.orst.edu (Guangliang He) (05/05/89)
In article <3540@udccvax1.acs.udel.EDU> conan@vax1.acs.udel.EDU (Robert B Carroll) writes: >In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >> >>It it safe to assume when writing a program which manipulates >>directories that . and .. will always be the first two entries in a >>directory? > >NO, its not save to assume that. >try "touch #abcd" then 'list' the directory. > Yes, 'ls' shows #abcd before '.' and '..' . *BUT* if you read the directory in a C program, it still shows that #abcd is sitting behind '.' and '..' . *********************************************************************** * USMAIL: Guangliang He * INTERNET: ghe@PHYSICS.ORST.EDU Department of Physics * ghe@jacobs.CS.ORST.EDU Oregon State University * BITNET: hegl@orstvm.bitnet Corvallis, OR 97331 * PHONE: (503) 754-4631 * ***********************************************************************
john@polyof.UUCP ( John Buck ) (05/05/89)
In article <11493@ulysses.homer.nj.att.com>, ekrell@hector.UUCP (Eduardo Krell) writes: > In article <2778@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: > >To beat this horse quite dead, any leading character that would sort before > >the period will place the filename before the . and .. in a directory > >listing. > That's because "ls" sorts the directory entries by default. The original > question was about readdir() which doesn't. Use "od" or write a small > program using opendir() and readdir() and you'll see that "." and ".." > are the first and second entries. The '-f' option of 'ls' lists directories (and other files, for that matter) in "directory order"; it performs NO sorting. Usually, '.' and '..' will appear first. This is not necessarily true; some wise-guy can easily change the order of things in directories using fsdb, or some other tool(s). The bottom line is, since you are readdir()ing anyway, how hard is it to add the test after each readdir? C'mon, it is not going to slow things down. An extra compare (or two) is worth the grief you may suffer later. After all, how many entries are in the directory? 1000? 2000? how long does 1 or 2K compares take these days? /* Notice this first compare will fail most of the time, and the * rest of this 'if' won't even get executed */ if(dp->d_name[0] == '.' && (dp->d_name[1] == '\0' || (d->d_name[2] == '\0' && dp->d_name[1] == '.'))){ continue; } John Buck john@polyof.poly.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/05/89)
>In article <3540@udccvax1.acs.udel.EDU> conan@vax1.acs.udel.EDU (Robert B Carroll) writes: >try "touch #abcd" then 'list' the directory. The order in which "ls" lists directory entries has nothing to do with their order in the directory.
toivanen@tukki.jyu.fi (Jari Toivanen) (05/06/89)
> From: mchinni@pica.army.mil (Michael J. Chinni, SMCAR-CCS-E) > > On our systems (DoD Army) we have a program which uses several files that > begin with a "," for storage. These all apear before "." and ".." in the > directory listings. Therefore, I would say that you cannot make you > assumption. Also, users sometimes create files (by accident) that may begin > with some of the following characters, all of which would apear before "." and > "..": ! " # $ % & ' ( ) * + , - This is already second article that says that files (or directories) which begins with character that appears before dot ('.') character appears also directory before "." and ".." entries. This is true if you use ls command or shell which expands wildcards, because they sort file names before they shows them. But if you are using directory(3) c library calls you get files in the order which they really appears in a directory. When you create a directory (in BSD or SysV) then the kernel also creates "." and ".." entries in the new directory. That's why "." and ".." entries are first ones in a directory. Also you can remove those entries only by removing the directory where they locate. So they should be first entries in a normal directory. I not sure is this true for remote file systems. I think that it's not good to presume so although it might be true almost always (if not even always). -- Jari Toivanen Segments are for worms ;-) Math student at Internet: toivanen@tukki.jyu.fi University of Jyvaskyla, Finland Bitnet: toivanen_jar@finjyu.bitnet
rml@hpfcdc.HP.COM (Bob Lenk) (05/06/89)
In any file system implementation derived from any of the traditional AT&T or BSD systems, if the directory was created by mkdir(1) or mkdir(2) and nothing abnormal has occurred, the first two entries will be "." and "..". However, that includes a number of assumptions that reduce portability. There are other file system implementations. Even on traditional implementations it is possible for superusers to mknod(2) directories without "." and ".." or to unlink(2) these entries. It is easy enough to write code that tolerates but does not depend on seeing these entries anywhere in a directory (which is what POSIX requires for portable applications). Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com
jwc@unify.UUCP (J. William Claypool) (05/06/89)
In article <2778@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >In article <3540@udccvax1.acs.udel.EDU> conan@vax1.acs.udel.EDU (Robert B Carroll) writes: >>In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >>>It it safe to assume when writing a program which manipulates >>>directories that . and .. will always be the first two entries in a >>>directory? >> >>NO, its not save to assume that. >>try "touch #abcd" then 'list' the directory. > >To beat this horse quite dead, any leading character that would sort before >the period will place the filename before the . and .. in a directory >listing. The ascii characters that will do this are space, !, ", #, $, %, >&, ', (, ), *, +, ,, and -. I haven't tried it, but I bet you can get the >nonprinting ascii characters to do it too. There are 32 of those. All of this has nothing to do with the order of directory entries. The 'ls' command sorts the directory entries according to the options before displaying them. The default sort order is alphabetical by name. I suspect that . and .. will always be first in the directory (unless you somehow manage to remove them) since they are created as the first two entries by the mkdir(2) system call. -- Bill Claypool (916) 920-9092 jwc@unify.UUCP {{ucdavis,csun,lll-crg}!csusac,pyramid,sequent}!unify!jwc
devusr@relay.nswc.navy.mil (05/06/89)
>> Jonathan I. Kamens <jik@athena.mit.edu> : >> >> It it safe to assume when writing a program which manipulates >> directories that . and .. will always be the first two entries in a >> directory? > Michael J. Chinni <mchinni@pica.army.mil> : >On our systems (DoD Army) we have a program which uses several files that >begin with a "," for storage. These all apear before "." and ".." in the >directory listings. [...] Also, users sometimes create [such] files [...] but michael, just because ls reports the files in that order doesn't mean that they are stored in the directory in that order. no, the "dot and dot-dot come first" assumption is invalid for other reasons: doug gwyn mentioned one, and i can think of other scenarios where .. gets unlinked and relinked to some other inode. however, i think that there is a tradeoff between simple code which is going to work in 98% of the existing environments, and (marginally) more complicated code which will work everywhere :-) folks need to decide just how portable their program should be, and whether the effort to get to that level is warranted. in this case, it doesn't seem to be that hard to cover all the possibilities. BTW, scandir(3) provides an easy way to exclude dot-files. perhaps its use is called for in this case. /dave --- Dave Paulson dpaulso@relay.nswc.navy.mil (703)663-2137 "I've upped my standards; now up yours" -- Pat Paulsen
guy@auspex.auspex.com (Guy Harris) (05/06/89)
>After checks on our file system, I found that this assumption is PROBABLY >correct. However, this type of thing is EXTREMELY DANGEROUS, unless it is >part of the definition of the directory structure (It might well be - if it >is ignore this message and I'll be eating flames). It's not part of the definition of the "readdir" interface, which is what matters. In POSIX, for example, there is no guarantee that there will be any "." or ".." entries *at all* - while path names with "." and ".." have to work, it is not required that directory entries with those names actually appear in directories, or that "readdir" return entries for them. Don't assume you'll *ever* see them when reading a directory, if you can possibly avoid it.
bzs@bu-cs.BU.EDU (Barry Shein) (05/06/89)
>NO, its not save to assume that. >try "touch #abcd" then 'list' the directory. Gack, "ls" sorts its output by default, try "ls -f" or just "od -c" the directory and see what you get. It's still not a safe assumption, but for other reasons. -- -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
bill@bilver.UUCP (bill vermillion) (05/07/89)
In article <535@biar.UUCP> trebor@biar.UUCP (Robert J Woodhead) writes: >In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: >>It it safe to assume when writing a program which manipulates >>directories that . and .. will always be the first two entries in a >>directory? >No. It isn't safe to make this assumption. Even if it is true on your >machine, it may not be on another implementation (it isn't on my Xenix >box, according to a quick test using ``l''), and it surely will be changed >_just_to_smite_your_program_ at some time in the future. I think if you will look at the Xenix manual, section F, entry DIR, you will find that Xenix follows the others. Even the manual is the same "by convention the first two entires in each director are "dot" (.) and "dotdot" (..) ... "l" is a program that sorts directory entries. It has NO relationship to how they are stored in the directory. To see this go to your directory you did an "l" on and try od -x . (octal dump of the dirctory you are in). You will see that . and .. are the two first entries. If you think about it, it has to be this way, doesn't it. You can't use a directory until you create it. To create it you must make an entry for it's parent and itself. Only then can you add other entries. And you can't remove them and access the directory. -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
rjw@attibr.UUCP (Ralph J. Winslow x7774) (05/07/89)
In article <11108@bloom-beacon.MIT.EDU>, jik@athena.mit.edu (Jonathan I. Kamens) writes: > > It it safe to assume when writing a program which manipulates > directories that . and .. will always be the first two entries in a > directory? > > Jonathan Kamens files whose names start with "-" will precede . and .. (at least on V.3.2 on the 6386) attibr|atti01!rjw
jik@athena.mit.edu (Jonathan I. Kamens) (05/08/89)
Well, by now there have been any number of intelligent responses to my original question which confirmed my original suspicions, and any number of quite moronic responses which talk about how files will appear before . and .. in the listing when you use ls. To summarize, most Unix filesystems place . and .. first in the directory by convention; however, this is not a requirement of the filesystem, and therefore it should not be relied upon by a program, especially a program that expects to run on many different architectures usefully. One person suggested that I use scandir to filter out . and .. from a directory before dealing with the entries in it. I might just end up doing that, but I want to examine the code for scandir first and find out exactly what it's doing -- it may not be very well-optomized and therefore time constraints will outweigh its usefulness. I have at this point modified my code so that it uses a macro is_dotfile to check each file before doing anything with the file. The macro is_dotfile is defined as follows: #define is_dotfile(A) ((*A == '.') && \ ((*(A + 1) == '\0') || \ ((*(A + 1) == '.') && \ (*(A + 2) == '\0')))) Using this macro, most runs through the loop will only require one comparison since most files will not start with `.'. Thanks to all who responded. Jonathan Kamens USnail: MIT Project Athena 410 Memorial Drive, No. 223F jik@Athena.MIT.EDU Cambridge, MA 02139-4318 Office: 617-253-4261 Home: 617-225-8218
nvt9001@belvoir-emh3.army.mil (DoN Nichols) (05/08/89)
Sorry about no quote from original msg, but with this mailer and the Wizards-Stuff coming in digest form, that is a royal pain. Also, the response has been delayed by a constipation of the net between sem.brl.mil and here. As a real example of a case where '.' and '..' are not in a standard order, take the case of a mew 'mkdir(1)' posted to the net about a year ago. (Not sure of the original date, but it was from Dominick Samperi (nyu.edu!manhat!samperi) or (rutgers!hombre!samperi). This mkdir had the option of making all necessary intermediate directrories between you and the directory specified. This seemed like a 'good thing', so I compiled it, and put it into service. This system (not the one from which I am posting) is an old V7-based one by UniSoft, and has a program called 'vchk(1)', which goes thru checking permissions, ownership, version numbers, etc. (It also could optionally update the system from another one if the other one were within communication range.) Anyway, next time I ran vchk, it started spitting out lots of complaints about "entries for '.' and '..' screwed up!". A check with od showed that the two entries were exchanged, so that '..' was before '.'. This wouldn't break the program in question, but still was non-standard, and an indication not to trust *ANYTHING* which is not enforced by the kernal *ON ALL SYSTEMS*. The program was sufficiently useful so I took the time to fix the offending code, and still use it. If it weren't for 'vchk(1)', I probably would never have known of the problem. I never reported to the author, because my mailer has trouble with bang-paths, and I don't know how to mail to him, but if he is interested, and can give me a domain-path which I can reach from milnet, I will be glad to send him diffs. Good Luck DoN. (nvt9001@belvoir-emh3.army.mil)
rec@dg.dg.com (Robert Cousins) (05/08/89)
In article <2892@osiris.UUCP> consult@osiris.UUCP (Unix Consultation Mailbox (Phil)) writes: > >That ain't no horse, it's a red herring. > >The order of files in a "directory listing" (using ls, which by default >sorts everything by ASCII collating sequence before writing it to stdout) >has nothing to do with the real order of the files in the directory. Actually, when one types in "ls *", the shell places all of the filenames which match the "*" on the command line as a replacement. It is the SHELL which sorts them in alphabetical order. For example, if one types "echo *", the names of all files are listed in alphabetical order. Note that the shell does not automatically insert filenames which begin with "." by convention. It sees them, but doesn't use them unless specifically instructed to do so. >You >can only force that order by writing the directory yourself, which is >something permitted only to root and not recommended anyway. > > >phil On some versions of Unix, even this is not allowed. Any highly secure unix I've ever heard of will not allow directory modification to take place on a mounted file system. Robert Cousins Speaking for myself alone.
tvf@cci632.UUCP (Tom Frauenhofer) (05/08/89)
In article <19473@adm.BRL.MIL> mchinni@pica.army.mil (Michael J. Chinni, SMCAR-CCS-E) writes: >> From: "Jonathan I. Kamens" <jik@athena.mit.edu> >> It it safe to assume when writing a program which manipulates >> directories that . and .. will always be the first two entries in a >> directory? >On our systems (DoD Army) we have a program which uses several files that >begin with a "," for storage. These all apear before "." and ".." in the >directory listings. Were you using the sorting options on your listing commands? Just because the listing is displayed in some order doesn't mean that the files in that directory are laid out in that order. BTW, I wouldn't depend on "." and ".." being the first two listings in a directory. It may be a convention, but I fail to see how hard it would be to just write a little extra code to skip these entries when you find them. Thomas V. Frauenhofer ...!rutgers!rochester!cci632!ccird7!tvf *or* ...!rochester!cci632!ccird7!frau!tvf *or* ...!rochester!rit!anna!ma!tvf1477 FRAU BBS: (716) 227-8094 2400/1200/300 baud - log in as "new" to register
guy@auspex.auspex.com (Guy Harris) (05/09/89)
>I think if you will look at the Xenix manual, section F, entry DIR, you will >find that Xenix follows the others. Even the manual is the same "by >convention the first two entires in each director are "dot" (.) and "dotdot" >(..) ... None of which is surprising, since Xenix is (despite places I've seen referring to it as a "UNIX look-alike") derived from AT&T code. >You will see that . and .. are the two first entries. > >If you think about it, it has to be this way, doesn't it. No, as a matter of fact, it doesn't. >You can't use a directory until you create it. To create it you must >make an entry for it's parent and itself. No, not necessarily. On UNIX systems that don't have the "mkdir" system call, directories are generally created by privileged code (e.g., in the "mkdir" command) which: 1) does a "mknod" to create an *empty* directory; 2) makes the "." and ".." links. Privileged code could do 1) without 2) if it wished. On file systems other than the standard UNIX ones, you could imagine "." and ".." being handled by special-case code (even with the standard UNIX file systems, ".." is treated as a special case in some places), and directories having neither "." nor ".." entries. >Only then can you add other entries. Wrong. You most definitely *can* make entries in a directory that lacks "." or ".." entries (otherwise, how could the aforementioned privileged code work? And no, it doesn't require privilege to make an entry in such a directory; the only reason making the "." and ".." entries requires privilege is that it requires making hard links to directories, which is a privileged operation.). >And you can't remove them and access the directory. Oh, yes, you can.
dik@cwi.nl (Dik T. Winter) (05/09/89)
In article <19502@adm.BRL.MIL> nvt9001@belvoir-emh3.army.mil (DoN Nichols) writes: ... (about a new mkdir) ... > one were within communication range.) Anyway, next time I ran vchk, it > started spitting out lots of complaints about "entries for '.' and '..' > screwed up!". A check with od showed that the two entries were > exchanged, so that '..' was before '.'. No bug in the new mkdir but in vchk. In Unix V6 . and .. where interchanged for the root directory with respect to other directories. -- dik t. winter, cwi, amsterdam, nederland INTERNET : dik@cwi.nl BITNET/EARN: dik@mcvax
drm@tcom.stc.co.uk (David Monksfield) (05/09/89)
In article <11108@bloom-beacon.MIT.EDU> jik@athena.mit.edu (Jonathan I. Kamens) writes: > >It it safe to assume when writing a program which manipulates >directories that . and .. will always be the first two entries in a >directory? <<numerous replies (around 23 to date) omitted>> Whatever happened to the principle that E-MAIL is used for replies to questions such as this? I don't mind reading one further posting containing an answer or set of alternative answers, but having to plough through a score of articles all either saying "yes" or "no" or giving some incorrect/inappropriate information (ie. directories as listed by ls) or correcting the incorrect replies. This seems a tremendous waste of net bandwidth (IMHO). So may I suggest that, if you post a question to a newsgroup such as this one, add a request to the effect: "Please send replies by e-mail to <wherever>. If there is sufficient interest I will post a summary of the replies." That goes for this message as well! -- Regards, |||||||| ||||||||| |||||||| "The Mighty Hordes Dave Monksfield ||| ||| ||| of Albion can't make |||||||| ||| ||| it I'm afraid... drm@tcom.stc.co.uk or ||| ||| ||| ...!mcvax!ukc!stc!drm |||||||| ||| |||||||| "I've brought the +44 279 626626 x2822 STC Telecommunications sick note."
frank@zen.co.uk (Frank Wales) (05/11/89)
In article <167@dg.dg.com> rec@dg.UUCP (Robert Cousins) writes: >In article <2892@osiris.UUCP> consult@osiris.UUCP (Unix Consultation Mailbox (Phil)) writes: >>That ain't no horse, it's a red herring. >> >>The order of files in a "directory listing" (using ls, which by default >>sorts everything by ASCII collating sequence before writing it to stdout) >>has nothing to do with the real order of the files in the directory. > >Actually, when one types in "ls *", the shell places all of the filenames >which match the "*" on the command line as a replacement. It is the SHELL >which sorts them in alphabetical order. That's a herring of another colour. Try: ls `ls|sort -r` How the shell expands metacharacters is irrelevant to what ls does with its arg list once it gets it, options excepted. -- Frank Wales, Systems Manager, [frank@zen.co.uk<->mcvax!zen.co.uk!frank] Zengrange Ltd., Greenfield Rd., Leeds, ENGLAND, LS9 8DB. (+44) 532 489048 x217
allbery@ncoast.ORG (Brandon S. Allbery) (05/15/89)
As quoted from <28440@cci632.UUCP> by tvf@cci632.UUCP (Tom Frauenhofer): +--------------- | In article <19473@adm.BRL.MIL> mchinni@pica.army.mil (Michael J. Chinni, SMCAR-CCS-E) writes: | >> From: "Jonathan I. Kamens" <jik@athena.mit.edu> | >> It it safe to assume when writing a program which manipulates | >> directories that . and .. will always be the first two entries in a | >> directory? | | BTW, I wouldn't depend on "." and ".." being the first two listings in | a directory. It may be a convention, but I fail to see how hard it would be | to just write a little extra code to skip these entries when you find them. +--------------- That's the way I do it; I also check for d_name[0] == '.' first to speed up the check, as there are almost always more files not beginning with '.' than files that do in any non-trivial case. (That is, the speed doesn't matter in someone's home directory that contains six dot files and no non-dot files, as happens on a certain system I use when a new user is created.) Also: once, I managed to confuse a System III directory when attempting to relink the kernel. (I passed the wrong path to make, and it proceeded to attempt to create the new kernel as "..", which "ld" promptly DELETED when it couldn't write on it.) After discovering this, I used /etc/link to replace the ".." entry... by which time I had created a file for some reason, so ".." ended up somewhere in the middle of the directory. Fsck didn't care about its new location; neither did ls or anything else. One final comment: if you KNOW that the file system is Unix, you can be reasonably certain that the first two entries are "." and "..". (Excepting, of course, situations like the above.) In the case of the HP9000 Unix that was mentioned previously, I've heard that the underlying filesystem is NOT a Unix filesystem; the kernel maps it onto an HP file system, and "." and ".." are magic cookies handled by namei. This is likely to be common whenever Unix is running on top of something else, e.g. (early?) Primix, DG's version of Unix, Eunice, etc., if the underlying OS does not itself use something similar. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
allbery@ncoast.ORG (Brandon S. Allbery) (05/15/89)
As quoted from <167@dg.dg.com> by rec@dg.dg.com (Robert Cousins): +--------------- | In article <2892@osiris.UUCP> consult@osiris.UUCP (Unix Consultation Mailbox (Phil)) writes: | >The order of files in a "directory listing" (using ls, which by default | >sorts everything by ASCII collating sequence before writing it to stdout) | >has nothing to do with the real order of the files in the directory. | | Actually, when one types in "ls *", the shell places all of the filenames | which match the "*" on the command line as a replacement. It is the SHELL | which sorts them in alphabetical order. For example, if one types +--------------- But "ls" ALSO does so. Try "ls .". +--------------- | >You | >can only force that order by writing the directory yourself, which is | >something permitted only to root and not recommended anyway. | | On some versions of Unix, even this is not allowed. Any highly secure +--------------- On MOST versions of Unix, it's not allowed. Unless, of course, you mean by using adb on the device and mangling the directory blocks yourself.... ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser