Le 22 déc. 06 à 17:17 Soir, [EMAIL PROTECTED] a écrit:
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.
I think I saw it incorrectly. In your explanations, you speak using
the "file system" terms.
My definition of a file system was, somehow: a part of the OS that
handles files and folders (and related stuffs).
Now I see that differently. Apparently, a file system can be a part
of something else than an OS. So, for example, if, with my own
application, I define that a document saved to disk consists of a
file with extra metadata in it and 2 folders needed to read back the
document, I created my own file system (which still relies on the
file system of the OS to store them). I'm too complex or is it 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.
Good idea.
However, a solution allowing users of RB 5.5 to also know these specs
seems better for me, since I still use that version.
Thank you, Joe._______________________________________________
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>
