[haiku-development] Re: fixing ticket #5335
- From: Joseph Groover <looncraz@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 18 Mar 2012 19:42:06 -0500
On 3/18/2012 16:44, Ingo Weinhold wrote:
The ino_t is provided by the respective file system. In general it
cannot be considered stable. ATM due to the way BFS is implemented the
inode numbers are stable, but that can easily change, e.g. when live
defragmentation is introduced. The rather extensive use of entry_refs
in the Haiku API is therefore a bit troublesome. Persisting entry_refs
should be avoided in any event.
Yes, I considered that after posting my e-mail and wasn't entirely
certain how to address it without just creating a database of paths and
generating ids for reference on creation (and updating the entries on
each relevant change). They would have to be stored in some way, which
is a problem for file systems that are modified by other OSs as well.
It would allow concurrent batching and would greatly simplify
the caching tasks of some of my projects... meaning we could move a
folder while copying contents into it without a hiccup...
The latter should already be possible as long as the copy routine
implementation doesn't use path based functionality. The storage kit API
(BEntry, BDirectory, and friends) does support it, as does the POSIX *at()
functionality.
Intriguing, I will have to give that a try...
There's already find_directory() which provides an indirection for well-known
directories, which already allows us to move/rename those between releases.
True, and we could (should?) implement BDirectory(B_SOME_FOLDER) and
BFile(B_SOME_FOLDER, "filename", ...) if that hasn't been discussed (or
implemented) already...
As for the bug - I am rather certain it is localized to Tracker,
especially given the prior behavior was to rename the incoming
conflicting name so as to not conflict... a centralized ID could solve
naming conflict by exempting Trash from unique names, or you could just
restore the aforementioned behavior.
I don't see how any kind of ID would help in this respect. The trash is implemented as a directory (per volume) and as such its entries
have to have unique names. The names of trashed entries simply need to be made unique -- e.g. if the trash already contains an entry
"Foo" the next trashed "Foo"s would need to be renamed to "Foo 1", "Foo 2", and so on (I find the
"copy" suffix the ticket mentions rather unsuitable). IIRC the trash entries already have an attribute that refers to their
original location. I don't know whether that does include the name of the entry itself. If not, a new attribute storing the entry name
could be added. Ideally the trash window would show the original entry name instead of the actual name. The addition of a "delete
on" attribute (which could also be displayed by default) might be a good idea, too.
CU, Ingo
Having a unique ID for each folder would solve part of the problem - you
would just permit name collisions in the Trash folder (or maybe even
system wide) - however, I like the idea of changing the name and faking
it in the UI better. Simpler as well. So I'd say that idea was a bust ;-)
Now the only real advantage would be storing an ID to access a given
folder rather than the path (which can greatly simplify a few
programs...which could just do it on their own) .. while creating an
additional location for failure and corruption.
Oh well, just another one of those things that seems great on the
surface and then falls flat when looking at the entire situation. :-(
Thx,
--The loon
Other related posts:
