On Dec 22, 2006, at 15:42 UTC, Arnaud Nicolet wrote: > I recently discovered that the "visible" property of a file in a > virtual volume cannot be set (I set f.visible=false and, when I check > again, the property stays on true). Same thing apply to the locked > property.
True, the virtual filesystem, doesn't support that metadata. (Of course there's nothing that could be done with such metadata either, except to read it back... so I guess you could make up your own place to store this info, e.g. in a special file like OS X does for Finder data.) > On the other hand, I can change the name of the file and > its MacType, that's all I tried. So it appears that some properties > are not applicable to files in virtual volumes. Right, or more generally: different file systems support different metadata and other behaviors. Some are case-sensitive, some are not; some support a full Unix permissions model while others do not; some have aliases and others don't; some are multi-forked and others are single-forked; etc. The virtual file system supports name and type codes, but does not support creator codes, aliases, locked/visible bits, Unix permissions, resource forks, etc. It's also case-insensitive IIRC. Again IIRC, it supports creation and modification dates. It doesn't support any special file formats though; SaveAsPicture, OpenAsSound, etc., will not work with it (since those formats are supported by the OS, but there isn't much of an OS associated with a virtual volume). > Files in a virtual volumes seems a bit paradoxical for me. Some > properties must exist (name, or directory, for example), some don't > have to (e.g ResourceForkLength) and some are, at the moment, > indeterminate (visible, creation date, modification date, locked, > etc. ). I'm not sure what you mean by that. There's nothing indeterminate about it; the VFS doesn't support resource forks any more than Windows does, nor does it support the metadata noted above. > Since the "alias" property is only applicable on Macs, where > the file contains at least an "alis" resource, since no resources are > allowed in a virtual volume, the "alias" property is certainly not > useable. Right. > Is there a list available somewhere which shows what properties are > supported for files in virtual volumes? Apparently, there is no > information in the Language Reference. Not entirely true; the VirtualVolume entry says: "Filenames can be up to 223 bytes long. Paths are not supported, but directories are (e.g., create a virtual directory with the CreateAsFolder method of the FolderItem class, and navigate to it with the Child or Item methods of this class). The virtual file system supports four-byte type codes (accessed via f.MacType), but does not support creator codes." However, I agree that this isn't a complete spec. A feature request to have this fleshed out a bit seems appropriate to me. Best, - Joe -- Joe Strout -- [EMAIL PROTECTED] Verified Express, LLC "Making the Internet a Better Place" http://www.verex.com/ _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
