[haiku-development] Re: fixing ticket #5335
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 18 Mar 2012 22:44:31 +0100
Joseph Groover wrote:
> On 3/18/2012 13:54, Abhinandan Ramprasath wrote:
> > I thought of fixing this bug by creating a folder id/key and assign it
> > to each folder so that each one will be represented uniquely. The list
> > of assigned ids/keys can be stored on a file/databse to make sure that
> > it is never assigned again. So, The integration/generation of this
> > id/key with the folder must take place during every operation
> > involving the file(copy,cut etc). I'd love to solve the bug myself
> > given the guidance.
> >
> > I'm new to haiku and it'll be great if someone could help me out
> > fixing this bug.
>
> If the system would just keep ino_t directory (see entry_ref) the same
> for each folder, that would give us a unique and invariable identifier.
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.
> Not sure how deep that goes...
>
> I would certainly prefer to have a unique -and immutable- id for each
> folder.
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.
> and ordain
> specialized identifiers for certain folders (such id 0, which could vfs
> '/', and 1337 which could be anything /etc/... once the system was fully
> migrated we could rename folders at will).
There's already find_directory() which provides an indirection for well-known
directories, which already allows us to move/rename those between releases.
> I'd certainly prefer storing
> an ino_t (int64, IIRC) rather than a string...
Sure, that would be convenient, but for the reasons mentioned above it simple
doesn't work.
> 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
Other related posts:
