BEntry fails to add volume name to BPath (non BeFS volumes)

[smallstepforman]

When receiving an entry_ref from RefsReceived(), and constructing a BPath from the BEntry, if the file originates on a non BeFS volume, the volume name is not passed to BPath.

I have a BeFS volume and an NTFS volume. I'm attempting to drag/drop the following file: /MyNtfsPartition/Videos/video_01.mp4

The following code is used to receive an entry_ref:

void MyWindow :: RefsReceived(BMessage* message) {

entry_ref ref; for (int i = 0; message->FindRef("refs", i, &ref) == B_OK; i++) {

BEntry entry(&ref, true); if (entry.InitCheck() == B_NO_ERROR) {

BPath path; entry.GetPath(&path); printf("File path = %s\n", path.Path());

}

}

}

The output is /Videos/video_01.mp4. I was expecting /MyNtfsPartition/Videos/video_01.mp4. This obviously causes problems since I cannot open /Videos/video_01.mp4 since it fails to resolve the link.

When doing the same for BeFS files, there is no issue.

[smallstepforman]

Now it gets interesting. I've tried it with Read/Write Fat32 external disk and it works fine. So the original issue is only on a NTFS read only volume.

The mount point for the failed read attempt is: drw-rw-rw- 1 user root 8192 Jul. 21 17:30 'Basic data partition'

[smallstepforman]

Appending the following bit of code resolves the linking issue:

append the following: BVolume aVolume(ref.device); Directory aDir; aVolume.GetRootDirectory(&aDir); aDir.FindEntry(path.Path(), &entry, true); the path was initially scanned and can fail entry.GetPath(&path); second scan now works

EDIT - this is not necessary, the Heisenbug resolved itself. A tracker Window did once show the name of the directory as mangled, so that's 2 independant apps which exhibited the bug. If I find a reliable way to reproduce it, I will report back.

[smallstepforman]

OK, there is something else happening. One of my Tracker windows just showed the directory as /Videos. When I closed it and opend it, it now shows /'Basic data partition/Videos'.

So even Tracker got confused when displaying the path. This is a Heisenbug it seems.

And now no matter what I do, it always works. Even my original code which started me down this rabbit hole works fine.

I'm 100% sure that I had one Tracker window open which showed the mangled path. Ever since I closed and reopend the window, everything is fine. But I had a good hour of problematic path resolving, and even Tracker exhibited the wierdness.

[smallstepforman]

On the Desktop, the problematic parition is displayed as "953.3 GB NTFS Volume", however the mount point is 'Basic data partition'. Can this be something which trips path resolving?

[smallstepforman]

I've managed to reproduce it. I unmounted the device, remounted, and the very first Tracker access reproduced the issue. After retrying it now works. A screenshot of 2 attempts looking at the same directory.

[smallstepforman]

Tracker showing same directory with out mount point name

[smallstepforman]

I'm sorry about the noise, but I honestly cannot find a sure method to reproduce the problem. It's a hit/miss Heisenbug, it will show up roughly 20% of the time when opening a folder from tracker.

If I work with the entry_ref directly (via RefsReceived), I can access the file. If I convert to a BPath first, the volume name may be missing. BPath fails to resolve if the volume name is missing.

Haiku apps which just work with entry_ref are fine and wont exhibit the bug (eg. MediaPlayer). However, if you create a playlist then it will reveal itself since the entry_ref is not saved, the BPath is. If you use the Tracker addon to open a Terminal, it will fail.

[waddlesplash]

The NTFS driver is just really buggy and should probably be rewritten entirely (it is a wrapper around libntfs, which is what powers the Linux NTFS-3G driver, so that part is fine; our wrapper seems to have a lot of problems though.) I would be unsurprised if it was the culprit somehow.