[haiku-development] Re: fixing ticket #5335
- From: Abhinandan Ramprasath <abhiin1947@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 19 Mar 2012 10:29:21 +0530
On Mon, Mar 19, 2012 at 3:14 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> 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
>
> Changing the name of the folder instead of generating a unique key seems
like a better and easier solution. I'd love to get started on it.
Unfortunately i have very little knowledge about the operations of Haiku
and their code structure. Can u give me a few pointers on how to start off
or where to look for the bug?
Other related posts:
