Trying to design low level hard disk manipulation program
|
From: Bill Todd on 2 Oct 2006 21:27 dgay(a)barnowl.research.intel-research.net wrote: > Bill Todd <billtodd(a)metrocast.net> writes: > >> Benny Amorsen wrote: >>>>>>>> "BT" == Bill Todd <billtodd(a)metrocast.net> writes: >>> BT> Does this suggest that the file system should collate >>> BT> case-insensitive even while it addresses case-sensitive, so that >>> BT> such potential collisions can be easily found? >>> What do you mean by collate here? >> Precisely what I said, as I usually do. >> >> If you say that the results of >>> readdir() or equivalent should be returned in proper alphabetical >>> order, you really have to make that order per-user. My girlfriend and >>> I expect different collations. >> I am not interested in your collating preferences, or in your >> girlfriend's. I was asking whether a file system should collate >> insensitively to case in order to facilitate detecting unintended >> logical collisions created by case-sensitive names (with the implicit >> assumption that these might be sufficiently frequent - as contrasted >> with other conceivable forms of character-related collisions - to be >> worth addressing). > > I think you missed the point that the output of readdir is (and should > be) unrelated to the order presented to the user. I'm afraid that *you* missed the point: the question which I asked had absolutely nothing to do with the order in which directory contents would be presented to the user (assuming that it was different from the readdir order): it had to do with whether readdir should present contents in an order that would make it easy for higher-level code that did *not* wish to propagate fully case-insensitive behavior upward to catch name combinations that did not conform to that intent (since the assertion of those here who feel that names in the file system should be case-sensitive has been that such higher-level software should provide case-insensitivity when that was what the user wanted). - bill
From: Bill Todd on 4 Oct 2006 16:15 dgay(a)barnowl.research.intel-research.net wrote: > Bill Todd <billtodd(a)metrocast.net> writes: > >> dgay(a)barnowl.research.intel-research.net wrote: >>> Bill Todd <billtodd(a)metrocast.net> writes: >>> >>>> Benny Amorsen wrote: >>>>>>>>>> "BT" == Bill Todd <billtodd(a)metrocast.net> writes: >>>>> BT> Does this suggest that the file system should collate >>>>> BT> case-insensitive even while it addresses case-sensitive, so that >>>>> BT> such potential collisions can be easily found? >>>>> What do you mean by collate here? >>>> Precisely what I said, as I usually do. >>>> >>>> If you say that the results of >>>>> readdir() or equivalent should be returned in proper alphabetical >>>>> order, you really have to make that order per-user. My girlfriend and >>>>> I expect different collations. >>>> I am not interested in your collating preferences, or in your >>>> girlfriend's. I was asking whether a file system should collate >>>> insensitively to case in order to facilitate detecting unintended >>>> logical collisions created by case-sensitive names (with the implicit >>>> assumption that these might be sufficiently frequent - as contrasted >>>> with other conceivable forms of character-related collisions - to be >>>> worth addressing). >>> I think you missed the point that the output of readdir is (and should >>> be) unrelated to the order presented to the user. >> I'm afraid that *you* missed the point: the question which I asked had >> absolutely nothing to do with the order in which directory contents >> would be presented to the user (assuming that it was different from the >> readdir order): it had to do with whether readdir should present >> contents in an order that would make it easy for higher-level code that >> did *not* wish to propagate fully case-insensitive behavior upward to >> catch name combinations that did not conform to that intent (since the >> assertion of those here who feel that names in the file system should be >> case-sensitive has been that such higher-level software should provide >> case-insensitivity when that was what the user wanted). > > My point is that the order of results from readdir is *completely the > wrong level* to be dealing with issues of name clashes. Incorrect - at least in cases (such as the one I described) where it may be the *only* level where such clashes can start to be dealt with with anything resembling efficiency (i.e., in any manner that does not force complete inhalation of an arbitrarily large directory before being able even to begin to determine whether naming collisions may exist). Perhaps you should develop the discipline to keep re-reading material until you actually understand the issue being presented before presuming to comment repeatedly (and incompetently) on it. - bill
From: Bill Todd on 4 Oct 2006 19:38 dgay(a)barnowl.research.intel-research.net wrote: > Bill Todd <billtodd(a)metrocast.net> writes: > >> dgay(a)barnowl.research.intel-research.net wrote: >>> Bill Todd <billtodd(a)metrocast.net> writes: >>> >>>> dgay(a)barnowl.research.intel-research.net wrote: >>>>> Bill Todd <billtodd(a)metrocast.net> writes: >>>>> >>>>>> Benny Amorsen wrote: >>>>>>>>>>>> "BT" == Bill Todd <billtodd(a)metrocast.net> writes: >>>>>>> BT> Does this suggest that the file system should collate >>>>>>> BT> case-insensitive even while it addresses case-sensitive, so that >>>>>>> BT> such potential collisions can be easily found? >>>>>>> What do you mean by collate here? >>>>>> Precisely what I said, as I usually do. >>>>>> >>>>>> If you say that the results of >>>>>>> readdir() or equivalent should be returned in proper alphabetical >>>>>>> order, you really have to make that order per-user. My girlfriend and >>>>>>> I expect different collations. >>>>>> I am not interested in your collating preferences, or in your >>>>>> girlfriend's. I was asking whether a file system should collate >>>>>> insensitively to case in order to facilitate detecting unintended >>>>>> logical collisions created by case-sensitive names (with the implicit >>>>>> assumption that these might be sufficiently frequent - as contrasted >>>>>> with other conceivable forms of character-related collisions - to be >>>>>> worth addressing). >>>>> I think you missed the point that the output of readdir is (and should >>>>> be) unrelated to the order presented to the user. >>>> I'm afraid that *you* missed the point: the question which I asked had >>>> absolutely nothing to do with the order in which directory contents >>>> would be presented to the user (assuming that it was different from the >>>> readdir order): it had to do with whether readdir should present >>>> contents in an order that would make it easy for higher-level code that >>>> did *not* wish to propagate fully case-insensitive behavior upward to >>>> catch name combinations that did not conform to that intent (since the >>>> assertion of those here who feel that names in the file system should be >>>> case-sensitive has been that such higher-level software should provide >>>> case-insensitivity when that was what the user wanted). >>> My point is that the order of results from readdir is *completely the >>> wrong level* to be dealing with issues of name clashes. >> Incorrect - at least in cases (such as the one I described) where it may >> be the *only* level where such clashes can start to be dealt with with >> anything resembling efficiency (i.e., in any manner that does not force >> complete inhalation of an arbitrarily large directory before being able >> even to begin to determine whether naming collisions may exist). > > Clearly we differ in the relative importance of keeping low-level > abstractions simple vs supporting some little-justified > application-level need (i.e., I don't see this major need for this > efficiency you're presenting Then you should have answered to that effect (since that was precisely the question which I originally posed), rather than diverting the discussion into what appears to be a religious area for you (in the 'cleanliness is next to Godliness' sense). - how many things are going to call readdir > up to some point, detecting potential conflicts and not read the whole > directory? Examples, please. Especially given your current level of > discourse.) The point, idiot, is that even a *single look-up request* from an application which wishes to disallow (or at least call attention to) the existence of additional directory entries that differ only in case from the name provided encounters this situation: by presenting a mechanism that allows the existence of any such collisions (for in the view of the higher-level software they *are* collisions, even if the file system itself allows them to exist) to be easily determined the application (or possibly an intermediate library function) performing that otherwise-simple look-up is saved from having to inhale and analyze the entire directory on every look-up. You may not care about case-insensitivity, in which case you may feel that this is simply not an important problem to solve. Fine: that's your opinion, and that's what I was soliciting. But don't confuse your personal preferences on such matters with anything of more general significance. > >> Perhaps you should develop the discipline to keep re-reading material >> until you actually understand the issue being presented before presuming >> to comment repeatedly (and incompetently) on it. > > Ahh, insults. Are you capable of having a technical/design decision > without insulting people? Do you behave like this in person too? (I've > noticed that people are a lot more insulting when they don't have to say > things to people's faces...) Only with those who, by their repeated and unapologetic incompetence, merit it. Use of words such as 'stupid' to characterize the proposal which you've failed to understand increases the likelihood of such responses as well. - bill
From: Bill Todd on 5 Oct 2006 13:57 dgay(a)barnowl.research.intel-research.net wrote: > Bill Todd <billtodd(a)metrocast.net> writes: > >> dgay(a)barnowl.research.intel-research.net wrote: >>> Bill Todd <billtodd(a)metrocast.net> writes: >>> >>>> dgay(a)barnowl.research.intel-research.net wrote: >>>>> Bill Todd <billtodd(a)metrocast.net> writes: >>>>> >>>>>> dgay(a)barnowl.research.intel-research.net wrote: >>>>>>> Bill Todd <billtodd(a)metrocast.net> writes: >>>>>>> >>>>>>>> Benny Amorsen wrote: >>>>>>>>>>>>>> "BT" == Bill Todd <billtodd(a)metrocast.net> writes: >>>>>>>>> BT> Does this suggest that the file system should collate >>>>>>>>> BT> case-insensitive even while it addresses case-sensitive, so that >>>>>>>>> BT> such potential collisions can be easily found? >>>>>>>>> What do you mean by collate here? >>>>>>>> Precisely what I said, as I usually do. >>>>>>>> >>>>>>>> If you say that the results of >>>>>>>>> readdir() or equivalent should be returned in proper alphabetical >>>>>>>>> order, you really have to make that order per-user. My girlfriend and >>>>>>>>> I expect different collations. >>>>>>>> I am not interested in your collating preferences, or in your >>>>>>>> girlfriend's. I was asking whether a file system should collate >>>>>>>> insensitively to case in order to facilitate detecting unintended >>>>>>>> logical collisions created by case-sensitive names (with the implicit >>>>>>>> assumption that these might be sufficiently frequent - as contrasted >>>>>>>> with other conceivable forms of character-related collisions - to be >>>>>>>> worth addressing). >>>>>>> I think you missed the point that the output of readdir is (and should >>>>>>> be) unrelated to the order presented to the user. >>>>>> I'm afraid that *you* missed the point: the question which I asked had >>>>>> absolutely nothing to do with the order in which directory contents >>>>>> would be presented to the user (assuming that it was different from the >>>>>> readdir order): it had to do with whether readdir should present >>>>>> contents in an order that would make it easy for higher-level code that >>>>>> did *not* wish to propagate fully case-insensitive Whoops - that last should have been 'case-sensitive', though I hope that was made clear by the surrounding context. behavior upward to >>>>>> catch name combinations that did not conform to that intent (since the >>>>>> assertion of those here who feel that names in the file system should be >>>>>> case-sensitive has been that such higher-level software should provide >>>>>> case-insensitivity when that was what the user wanted). >>>>> My point is that the order of results from readdir is *completely the >>>>> wrong level* to be dealing with issues of name clashes. >>>> Incorrect - at least in cases (such as the one I described) where it may >>>> be the *only* level where such clashes can start to be dealt with with >>>> anything resembling efficiency (i.e., in any manner that does not force >>>> complete inhalation of an arbitrarily large directory before being able >>>> even to begin to determine whether naming collisions may exist). >>> Clearly we differ in the relative importance of keeping low-level >>> abstractions simple vs supporting some little-justified >>> application-level need (i.e., I don't see this major need for this >>> efficiency you're presenting >> Then you should have answered to that effect (since that was precisely >> the question which I originally posed), rather than diverting the >> discussion into what appears to be a religious area for you (in the >> 'cleanliness is next to Godliness' sense). >> >> - how many things are going to call readdir >>> up to some point, detecting potential conflicts and not read the whole >>> directory? Examples, please. Especially given your current level of >>> discourse.) >> The point, idiot, > > Kill file time, clearly. Your loss, I suspect. Interesting, however, that you chose this as your response to the example that you requested above and which I then provided - sounds kind of like an attempt to avoid the issue now that you may finally have some clue about what it was. If you haven't learned yet that politeness > helps earn respect, and that insults lead you to being ignored, it's > probably too late. I insult those who earn it (without regard to whether they approve), I'm respected by those whose respect I care about (even if they themselves may be inclined to somewhat more tact than I am): if there's a problem there, it has managed to escape me. Whether *you* ever understand the point here is largely a matter of indifference to me: your ignorance is really not my problem - especially if you choose to perpetuate it by removing yourself from a discussion that you can't seem to handle. I think that anyone else interested in this sub-topic now likely has seen sufficient explanation of it, so if you're going to stop bleating incompetently I suspect my job here is done (though it's worth noting that a potential alternative to a single directory structure that can be processed either case-sensitively or case-insensitively is an inheritable but over-ridable directory attribute that determines how any given directory must be processed). > >> is that even a *single look-up request* from an >> application which wishes to disallow (or at least call attention to) > > The recent conversion (though possibly not the whole thread) was on > readdir. So maybe you should be insulting yourself. No - I was just interpreting 'readdir or equivalent' (which was introduced by Benny Amorsen and then reused by you as an apparent synonym for my own discussion of internal collating sequence, so after your reuse of the term I went along with it) as something a bit more extended than the existing Unix implementation, since that (or something equivalent) would be required to support the feature I was describing. In particular, something able to return a list of case-varying synonyms in response to each single-level look-up request would be required for normal path-following by applications desiring case-insensitive behavior (or the ability to warn of the existence of synonyms), and grouping such synonyms in readdir output would make sense as well when readdir was used in the service of such applications (readdir, after all, is *already* designed to present directory contents to applications
From: Eric P. on 7 Oct 2006 15:14
prep(a)prep.synonet.com wrote: > > VMS has all of the above. > > Welcome to 1978. Yeah, its just that some aspects of WNT make me pine for the fjords of VMS. Eric |