Re: [Nautilus-list] Something weird

[Darin Adler <darin eazel com>]

> Files that are not directories appear to have their own directory
> metadata. It is always placed in ~/.nautilus/metafiles, i.e. the
> alternate location. You can observe this by changing the view used for
> a non-directory file (to Sample perhaps) and exiting.

One fix it to put this in the file metadata instead. Except that "/" doesn't
have file metadata, so we still want to put it in the directory or in a
parallel location for at least some cases.

> Essentially, nautilus_directory_get will work just fine on a URI that
> points to a file which is not a directory. This seems odd to me.

This part is working as expected. You can get a NautilusDirectory object for
something that might be a directory. All the I/O is asynchronous, so you
won't know until later whether there actually is a directory with that URI.
The problem comes from storing metadata in such a "directory".

> These sorts of things really ought to be set as file metadata inside
> the parent directory.

Agreed.

> Perhaps we need some better abstraction for referring to a URI's metadata
> independent of whether it happens to be directory or file metadata.

We just need to decide what the rule is about where we store the
information. We can decide then how to structure the code. In fact,
abstraction of where the metadata is stored is what got us into this mess,
as you alluded to above in your note about nautilus_directory_get.

There are three places for metadata right now. Metadata is stored in the
object itself (like "directory metadata"), it's stored in the object's
container (like "file metadata"), and it's stored in a parallel location
that's private to the user. We should sort out where the "View as" setting
should go in various cases (writable directories, unwritable directories,
files in writable directories, files in unwritable directories). Note that
storing data in the object vs. in the object's container vs. different
indexing techniques in the "private user" area have different behavior for
items that have multiple paths (more than one hard link).

    -- Darin