BFS formatted USB memory stick shows weird directory structure

[haiqu]

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.

[haiqu]

Mystery tree

[haiqu]

Mystery directory tree

[bga]

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).

[haiqu]

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

[anevilyak]

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.

[haiqu]

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.

[haiqu]

Formatted incorrectly

[anevilyak]

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

[haiqu]

Formatted correctly

[haiqu]

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.

[bga]

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.

[mmlr]

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.

[bga]

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).

[haiqu]

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.

[haiqu]

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.

[stippi]

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.

[haiqu]

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.

[stippi]

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).

[haiqu]

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

[mmadia]

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

[haiqu]

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.

[stippi]

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.

[haiqu]

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.