Opened 4 years ago

Last modified 4 years ago

#16441 new bug

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

Reported by: smallstepforman Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: File Systems Version: R1/beta2
Keywords: BEntry entry_ref BPath Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (1)

evidence.jpg (166.1 KB ) - added by smallstepforman 4 years ago.
Tracker showing same directory with out mount point name

Download all attachments as: .zip

Change History (8)

comment:1 by smallstepforman, 4 years ago

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'

comment:2 by smallstepforman, 4 years ago

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.

Version 1, edited 4 years ago by smallstepforman (previous) (next) (diff)

comment:3 by smallstepforman, 4 years ago

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.

Last edited 4 years ago by smallstepforman (previous) (diff)

comment:4 by smallstepforman, 4 years ago

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?

comment:5 by smallstepforman, 4 years ago

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.

by smallstepforman, 4 years ago

Attachment: evidence.jpg added

Tracker showing same directory with out mount point name

comment:6 by smallstepforman, 4 years ago

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.

Last edited 4 years ago by smallstepforman (previous) (diff)

comment:7 by waddlesplash, 4 years ago

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.

Note: See TracTickets for help on using tickets.