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)
Change History (8)
comment:1 by , 4 years ago
comment:2 by , 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
comment:3 by , 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.
comment:4 by , 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 , 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 , 4 years ago
Attachment: | evidence.jpg added |
---|
Tracker showing same directory with out mount point name
comment:6 by , 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.
comment:7 by , 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.
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'