Opened 10 years ago

Last modified 10 years ago

#3766 reopened bug

BFS formatted USB memory stick shows weird directory structure

Reported by: haiqu Owned by: stippi
Priority: normal Milestone: R1
Component: Applications/DriveSetup Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

Took one 2Gb USB stick which had been formatted as FAT32. Formatted the RAW drive (not the FAT partition) and got the result shown in the attached snapshot.

Attachments (4)

screenshot1.png (109.7 KB ) - added by haiqu 10 years ago.
Mystery tree
screenshot1.2.png (109.7 KB ) - added by haiqu 10 years ago.
Mystery directory tree
screenshot3.png (90.6 KB ) - added by haiqu 10 years ago.
Formatted incorrectly
screenshot2.png (82.8 KB ) - added by haiqu 10 years ago.
Formatted correctly

Download all attachments as: .zip

Change History (24)

by haiqu, 10 years ago

Attachment: screenshot1.png added

Mystery tree

by haiqu, 10 years ago

Attachment: screenshot1.2.png added

Mystery directory tree

comment:1 by bga, 10 years ago

This is expected. Every BFS partition has a Desktop dir. And a Desktop dir is, by default, a merging off all Desktop dirs. So what you are seeing are the contents of this virtual Desktop dir which will be the contents of the Desktop dir in your boot partition (as the Desktop dir in the USB stick is empty).

comment:2 by bga, 10 years ago

Resolution: invalid
Status: newclosed

comment:3 by haiqu, 10 years ago

Resolution: invalid
Status: closedreopened

Piffle. The Desktop doesn't live under the Home directory. See snapshot of a mounted HDD, attached.

in reply to:  3 comment:4 by anevilyak, 10 years ago

Resolution: invalid
Status: reopenedclosed

Replying to haiqu:

Piffle. The Desktop doesn't live under the Home directory. See snapshot of a mounted HDD, attached.

The special folder for the desktop is and always has been under home on a given volume, be it Haiku or BeOS. Feel free to ls -la /boot/home to verify that for yourself.

comment:5 by haiqu, 10 years ago

Resolution: invalid
Status: closedreopened

Yes, but not visible from the tree view! Sheesh.

Two shots attached. First shows a drive formatted with BFS from BeOS (screnshot2.png) and the next from Haiku (screenshot3.png)

As you can see in the latter case, you get circular directories.

Sorry about missing attachment, I was doing a build from BeOS and poor old NetPositive can't upload snapshots to this site, the button goes missing.

by haiqu, 10 years ago

Attachment: screenshot3.png added

Formatted incorrectly

comment:6 by anevilyak, 10 years ago

Is the one from Haiku missing the _trk/pinfo_le attribute on the Desktop folder by any chance? (on that particular disk)

by haiqu, 10 years ago

Attachment: screenshot2.png added

Formatted correctly

comment:7 by haiqu, 10 years ago

There's no way to tell. I just tried this on a real HDD and listattr failed. The drive also threw a General IO error when I restarted under BeOS and it needed to be re-initialized.

Right now I have serious doubts about both DriveSetup and mkfs.

comment:8 by bga, 10 years ago

Your original bug implied that there was a directory structure in the USB disk that was not supposed to be there. Eventually you changed what you said to match what you were really seeing.

As Rene pointed out, what happened is that the attribute that makes the Desktop show not to be show is missing or could not be read. This is most likely not related to DriveSetup or mkfs at all but to USB. There are still several glitches with USB in Haiku yet. At least for me, this bug is still invalid and you should maybe post a different one pointing the problem with the attribute mentioned.

in reply to:  8 comment:9 by mmlr, 10 years ago

Replying to bga:

This is most likely not related to DriveSetup or mkfs at all but to USB. There are still several glitches with USB in Haiku yet.

No this makes no sense. USB mass storage is a very simple protocol and as it is implemented right now there is exactly one command to read from the medium. Either it works or it doesn't. As it's only the low level data transport it can't cause such high level problems.

Also there aren't 'several glitches in USB' that I know of, so please make sure that you report issues you encounter.

comment:10 by bga, 10 years ago

In my own experience, and with all due respect to your work with the USB stack, how well or badly it works is heavily chipset dependent. in 3 different computers I have problems with USB and, usually, different problems. Also some things sometimes work once and then do not work when I try again (mounting a USB stick is one of those things. Sometimes it mounts, sometimes it just freezes tracker, sometimes it throws me to KDL). I also usually get timeouts with USB mass storage devices even after it mounted correctly and when I get those timeouts, it usually results in some form of data corruption.

Some of the bugs I reported. Some I did not because I did not found a reliable way to reproduce them. In any case, in my personal experience, there are still several glitches with USB (granted, at least some of them could be attributed to bad IRQ sharing handling, which is not USB's fault).

comment:11 by haiqu, 10 years ago

Guys, I can settle this. It happens on USB, ATA and ATAPI CD-RW. It isn't USB-specific. Feel free to reassign the category, I simply took my best guess.

comment:12 by haiqu, 10 years ago

BTW I think I've solved the mystery. The disk is being initialized, but not partitioned. I can get the same effect on a HDD by initializing in BeOS and then looking at it in Haiku.

Partitioning isn't in the DriveSetup menu either.

comment:13 by stippi, 10 years ago

Yes, this is currently a problem in the kernel backend. When the disk doesn't already have a partitioning scheme, then it should offer available schemes in the DriveSetup UI for initializing with (like "Intel Partition Map", "EFI GUID", "Amiga Disk System", ...). But that part of the implementation does not yet work.

comment:14 by haiqu, 10 years ago

In the meantime, DriveSetup should be writing to the partition map to show a default Intel partitioning scheme with the first partition using all the available space. I don't think that would require kernel support.

comment:15 by stippi, 10 years ago

Well, the backend for this lives both in kernel and in userland add-ons. It does not and should not live in DriveSetup in any case. Please just trust me on that one. At the moment, I cannot work on this stuff. We have one Google Summer of Code project application for this subject, and no-one worked or should work on any of the subjects that we have had applications for until after the slot allocations are announced (except for the students of course).

comment:16 by haiqu, 10 years ago

Cool, so that one's in progress. Is there a public list of GSoC projects?

comment:17 by mmadia, 10 years ago

Not until the 20th. Note: it is possible that students may be removed from the accepted list before then.

comment:18 by haiqu, 10 years ago

Further information: Initializing a HDD will exhibit this directory anomaly also. It goes away the first time the Home directory is viewed by selecting it from the tree browser, which is why nobody noctied this before.

I'd say it's just some property of /boot/home/Desktop that isn't being set during the build process. If you check a CD build you can see it, and also the /var directory.

comment:19 by stippi, 10 years ago

I am pretty sure that I came across code in Tracker which takes care of such things. For DriveSetup (or the backend which implements initializing), the fix is probably rather easy.

comment:20 by haiqu, 10 years ago

Yes, I expected it would be fairly simple. Of course you could not fix it in a CD build, unless the invisible directory characteristics could somehow be written into the image and transferred. But during a disk/stick format, sure.

Note: See TracTickets for help on using tickets.