From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,714a8558b02b32bb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-23 22:26:19 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshub.sdsu.edu!elnk-nf2-pas!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!pd7cy2so!shaw.ca!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Sat, 24 Jan 2004 00:26:13 -0600 Date: Sat, 24 Jan 2004 01:26:12 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GUI was Re: why Ada is so unpopular ? References: <100tkcshhdi686a@corp.supernews.com> <400FD340.3080603@noplace.com> <401122E6.4010405@noplace.com> <1074885602.416478@master.nyc.kbcfp.com> In-Reply-To: <1074885602.416478@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <-NOdnXxZvcuYjY_dRVn-vg@comcast.com> NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-gITCPwueWErpAQXyvi2o1b+2KaUp5YacSQA68/ff8mgdP3rf+8LfmrfQmXqBr1I7xhY/n/qjSqKafxq!ZOH1nuJhsqMvrp0f9dC36CE5TWflt0Yti0tryjM7nubqIiSlnZF0qxYz4L9zKQ== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:4759 Date: 2004-01-24T01:26:12-05:00 List-Id: Hyman Rosen wrote: > Also, while programs may treat directory operations as traversal > of static but potentially large data structures, it's actually > the case that the directory structure could be changing as the > program is running. I know of no way to get an atomic snapshot > of a directory structure. I do, but you have to have an OS that supports it. With Multics you could create a copy of a directory that you controlled as an atomic operation. It was actually done by creating a new directory entry and setting the "copy on write" bits in the new and old directory entries. Now if someone modified the original directory while you were walking through the new one, the OS basically marked the in memory copy of whatever segment of the directory was modified as the copy belonging to the old directory, and the copy on disk as owned by the new directory. That way both atomic operations can be atomic, and neither one actually involves allocating (disk or main) memory. > A standard directory package cannot finesse its way around this, > or ignore it, especially if it offers iterative traversal. What I usually do in this case on inferior operating systems ;-) is to read the directory in chunks. For a directory with only a few entries, one chunk is the whole directory and you can do things the simple way. If the directory is bigger than one chunk you have to do the messy version. Unfortunately, on many operating systems a directory is hashed and there is no sorted view of the directory. If you need to display the directory sorted by name, date, or whatever, there is no way to do it other than scan the entire directory creating a tree, and then display from the tree. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush