Norman Palardy wrote:
> so I'm suspecting the server's
> implementation of the afp protocol (netatalk) is the issue here
Yes, that's the part that matters. The background of this test is
this:
RB's "count" property of a folder is taken directly from what
the Mac OS functions returns if you inquire about properties
of a folder. These functions were designed after what the
Mac-preferred file system, HFS, could offer: The directory
entry about a folder contains the number of the items it
contains right there. So, to inquire about this number, it
does not actually have to read in the entire list of items
in the folder and count them, but rather just take this
one value that's already stored in the place where other
properties of a folder are stored.
This is not the case for most other file systems, though.
For example, a DOS (FAT) file system does not have this count
information, neither does it have some other properties that
the Mac OS function is expected to return anyways, such as
a backup date, even a creation date is not available, I
believe (only a modif. date). So, the Macintosh driver (file
system) that reads a FAT formatted disk needs to fill in
_something_ into the property fields even though it can't
find relating information on the FAT disk. So it has to
fill in something that makes sense. For the creation date,
it simply duplicates the value from the modification date.
And for the "count" value, it has to actually read the
entire subdir and count the number of items in it before
it can return the correct value. This is, however, quite
some extra work and, on slow media, such as CD-ROMs, can
add some extra time that can be making accessing disks
unpleasantly slow, since much more data has to be read.
So, instead, some file system found that the Finder never
really relies on this "count" value anyways, and so they
took the freedom to return a default value that was not
accurate, but it saved the file system to do a lot of
rather unnecessary reading of data from the disk.
My test app tries to find out about such "optimized"
(or call them lazy) file systems.
Most modern implementations, though, are using internal
caching that will still make the initial inquiry about
a dir rather slow, but this will become less of an issue
once the contents of that dir are getting accessed, too,
since the data is already in the cache, saving the read
accesses then.
And my own testing a few minutes ago shows that Apple's
file systems such as PC Exchange (for FAT) in OS 9 and
UFS in OS X do actually return the correct value.
The Linux file systems are also not having this "count"
information readily available, and the Mac-supporting
sharing software (netatalk) would need to do the manual
counting to get thru my test. But I wouldn't be surprised
if that software was a little more lazy, since I've
heard it causing other problems, and since it's a open
(free) development, it had perhaps not gotten the
professional attention a proper implementation would
need.
Another candidate that should fail is Novell's, but that's
quite old and I'd expect that no one here even has it
in use, or even heard of it :)
Thomas
--
Thomas Tempelmann,
http://www.tempel.org/rb/
http://www.tempel.org/software/
---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>
Unsubscribe:
<mailto:realbasic-nug-off at lists dot realsoftware dot com>
Subscribe to the digest:
<mailto:realbasic-nug-digest at lists dot realsoftware dot com>
.
|