Re: FAT32 USB stick and fat-handler [Bug Reports]

Forum Index

Board index » Development » Bug Reports » FAT32 USB stick and fat-handler

Browsing this Thread: 1 Anonymous Users

Bottom

Previous Topic

Next Topic Register To Post

« 1 2 3 (4) 5 6 7 »

cdimauro

Re: FAT32 USB stick and fat-handler

#34

Home away from home

Quote:

cybergorf wrote:
Quote:

cdimauro wrote:
What about not mounting the device when there's already another one with the same name? Maybe Wanderer can show a dialog reporting the issue, and inviting the user to use the physical device (HD1:, DH1:, et.c) to access it.

Well, if the volume is not mounted, you can not access the files on it and if you mount it, it needs a name.

So there no chance to just access it only as, for example, DU1:, right?

That's strange, because you should have the possibility to use the physical device name or the (logical) volume name. So, if the latter is missing, it should be accessible with the former. IMO.
Quote:

So maybe a dialog asking for an alternative name (offering a generic name as default option?)

Basically not mounting is what already happens as mounting obviously fails.
A dialog is also difficult during booting (well here we are again...).
A proper warning/dialog would need to be shown on all Desktops (Wanderer, Magellan, Scalos ...)

The system can collect all "conflicting volumes" and ask to the user to "disambiguate" everything after the book.
Quote:

I guess just mounting it with a generic name would be the thing most users would expect from an OS. Lets say a combination of original name and physical device to make it obvious:
A second "Sys:" on usb-stick becomes "DU1_Sys:"

I think it's better that the system appends a proper unique ID after the conflicting volume name, using a special character to separate it.

I don't know if it creates problems, but maybe the "/" might be used inside the "normalized" volume name, followed by a proper id.

For example: "System:" might be converted to "System/ :" where " " (ASCII 32) is the unique id available at the time, encoded using progressively the legal/allowed symbols (from the character set) available for encoding a filesystem identifier. When a single digit is not enough, two digits will be used, and so on. The unique id is volume-specific, in order to minimize the volume label length and it make it easier to recognize and enumerate the conflicting volume groups.

Posted on: 2015/5/15 20:27

ntromans

Re: FAT32 USB stick and fat-handler

#33

Home away from home

Not so sure about the device names being differentiated. I set up my different machines by simply cloning the hard drives by connecting the drive to be copied to into the 'master' machine, and have found if the devices have the same name (e.g. DH0:) AROS gets rather confused.

Actually, I had another odd issue today to throw into the mix. I put in a USB stick (fat format, not sure the exact type as it was someone elses) with no name. When I clicked on its icon, sys: opened instead. When I tied to copy to it via the shell using its device name, the files were copied to sys: too.

Cheers,
Nigel.

Posted on: 2015/5/15 17:02

ncafferkey

Re: FAT32 USB stick and fat-handler

#32

Home away from home

Quote:

DizzyOfCRN wrote:
I don't know what the fat-handler is up to when it tries to find the disk label and when it finds it, it uses it. It should not do that. It's a clear indication that such a volume already exist and it should give the inserted volume a new name.

AFAIR FAT volumes have a creation datestamp (if not in the superblock, perhaps in the volume directory entry), but it is often unset (i.e. set as some ancient default date such as 1st January 1980). Perhaps fat-handler should use the serial ID as the volume name if the volume name already exists (as it already does if there is no volume name set). Note that it is legitimate for fat-handler to match up a newly inserted disk with offline volumes: this is how locks are preserved between ejections.

AmigaOS replaces duplicate device names by using names such as DH0.0, DH0.1 etc. AFAIR.

Posted on: 2015/5/15 16:12

DizzyOfCRN

Re: FAT32 USB stick and fat-handler

#31

Home away from home

I formatted the USB sticks again on Linux and read the boot blocks

sdc1
sdd1

Linux(Fedora 20) seems not to insert the serial number at offset 0x27... Bummer as that could be used to identify different volumes, but then again there is no reason why Aros could not write it's own time stamp there.

There seems to be a difference between the boot blocks. Both are formatted to a clean state ~~and should in theory be identical if no identifiers are present.~~ There are flags that could have a difference even with identical drives.

Correction the serial number is at 0x43 on fat32 and seems to be implemented! :)

http://www.easeus.com/resource/fat32-disk-structure.htm

Maybe Aros should introduce a new flag for dos list (dvi_Type, on Aros it is dol_Type) that tells the volume is an "alien" filesystem that has no timestamp but a serial number instead? It would be the handlers responsibility then to differentiate different volumes.

Edit: There is a note on fat handlers disk.c that says: " /* Scan volume list for a matching volume (would be better to
* match by serial number) */"

Yes, indeed that would be preferable.

On DOS AddDosEntry there already is a check for identical names -> D(bug("[AddDosEntry] Name clash for %08lx->dol_Name: %b and %08lx->dol_Name %b\n", dl, dl->dol_Name, dlist, dlist->dol_Name));

So it is the fat-handler that needs to be fixed

Here's some more infohttp://www.digital-detective.net/documents/Volume%20Serial%20Numbers.pdf

Posted on: 2015/5/15 11:26

Edited by DizzyOfCRN on 2015/5/15 11:47:42
Edited by DizzyOfCRN on 2015/5/15 11:51:07
Edited by DizzyOfCRN on 2015/5/15 11:53:07
Edited by DizzyOfCRN on 2015/5/15 12:12:09
Edited by DizzyOfCRN on 2015/5/15 12:12:42
Edited by DizzyOfCRN on 2015/5/15 12:23:17
Edited by DizzyOfCRN on 2015/5/15 12:25:09
Edited by DizzyOfCRN on 2015/5/15 12:26:12
Edited by DizzyOfCRN on 2015/5/15 12:39:09

magorium

Re: FAT32 USB stick and fat-handler

#30

Home away from home

Quote:

DizzyOfCRN wrote:
When Aros adds a volume it should check if the volume name already exists, if so it should append a prefix number. But it seems that the volumes are never ejected on Aros but the volume is left behind even though no locks should be in use. Or does Wanderer lock the volume?

Wanderer does not lock the volume as far as i know (at least not by default) . Besides the obvious, I've only seen Dopus4 do that.

Quote:

DizzyOfCRN wrote:
I don't know what happens if I rename mu USB stick to LIBS :) or some other system assign name. Possibilities are endless... Maybe stick a bunch of USB sticks and name them SYS, S, L, LIBS... :)

Have fun screwing up things

Be aware though that you could potentially really screw up things.

Quote:

DizzyOfCRN wrote:
I don't know what the fat-handler is up to when it tries to find the disk label and when it finds it, it uses it. It should not do that. It's a clear indication that such a volume already exist and it should give the inserted volume a new name. It should also check if the name is reserved or dos should automagically rename such a label.

tbh, i have no idea how classic does that. Stupid, but i've never seem to have crossed that bridge (phun intended)

Posted on: 2015/5/15 9:36

magorium

Re: FAT32 USB stick and fat-handler

#29

Home away from home

cybergorf wrote:
Quote:

Now you lost me. It works exactly the same way?

How nice that every CD-rom drive in a system has the same device name.

But, reading through your response i see that you already covered yourself

Quote:

either there is some entry on the cd that defines a boot device or it does not and everything is as it always was.

So, basically just as how things are right now :-S

I do not see what that changes things, except for adding yet another equation into the mix:

If bootdevice option given to grub (no matter how that succeeds or fails as we haven't discussed yet) , then please act differently as curently is done and remove/relabel all mounted volume names that are going to be used by booting AROS from the given grub bootdevice entry.

Quote:

I did not do that.

In that case i have misinterpreted your remark "So bring them on! I am happy to hear them all!". Sorry.

Quote:

I was just looking for a solution for problem A.

Problem A is tight to option B in environment C depending on user D which leads to problem E.

Quote:

That is two or more volumes having the same name.

Which is perfectly find, except it oversimplificates the actual (underlying) problem at hand.

Quote:

YOU brought up the booting scenario and possible confusion the may occur, by giving a volume a generic name in case the name already exists.

Yes, _I_ indeed brought in the booting scenario as it is a valid one. Namely that volume names and assigns are needed during boot-process and that other named volumes in the system can screw that up. Which is more or less the same scenario as having two exact same volumes inserted as shown by dizzy and your solution as opted: 'rename' the volume name that was not created by the volume booted from bootoption= grub option.

Quote:

That's what "bootdevice" prevents and you could boot as expected, even with automatic renaming.

That's perhaps how you would like for things to work, but no.

Quote:

Again: duplicated names is exactly what I am trying to address here.

Again, actual practise isn't as simple as pictured.

Quote:

If we do it smart, there are no (new) problems with booting from other volumes.

It's not the booting from other volumes that causes the issues, it's the "hey i have a lot of volumes in my system that potentially can have a name that is used during boot or inserted while running" that is. See the difference ?

Quote:

The old problems with booting may stay the same - there your advise is most welcome: just don't do stupid things.

One of those would be: do not change behavior based on bootdevice= gruboption

Quote:

Booting was never my topic here

Yes, that much was clear to me now

.

So another addition then: if booting then ( mount and name things one way ) else ( mount and name things another way ).

Care to explain what is and/or isn't the definition of booting ( or not(booting), which also should do the trick

).

Quote:

"So what could possibly go wrong?" asked the captain of the Titanic.

Posted on: 2015/5/15 9:26

DizzyOfCRN

Re: FAT32 USB stick and fat-handler

#28

Home away from home

I don't know what happens if I rename mu USB stick to LIBS :) or some other system assign name. Possibilities are endless... Maybe stick a bunch of USB sticks and name them SYS, S, L, LIBS... :)

I don't know what the fat-handler is up to when it tries to find the disk label and when it finds it, it uses it. It should not do that. It's a clear indication that such a volume already exist and it should give the inserted volume a new name. It should also check if the name is reserved or dos should automagically rename such a label.

Posted on: 2015/5/15 7:22

cybergorf

Re: FAT32 USB stick and fat-handler

#27

Home away from home

Quote:

DizzyOfCRN wrote:
I renamed one of the USB sticks to SYS and it did not go too well. Aros should know that SYS is system reserved name and append some numbers after if such a volume is inserted. Or something...

Thats exactly what I am talking about.
Numbers or the device name as suggested (e.g. DU0_Sys).
Some unique identifier.

Posted on: 2015/5/15 7:14

DizzyOfCRN

Re: FAT32 USB stick and fat-handler

#26

Home away from home

I renamed one of the USB sticks to SYS and it did not go too well. Aros should know that SYS is system reserved name and append some numbers after if such a volume is inserted. Or something...

It might be because of the original problem of Aros not to differentiate volumes by some timestamp/ID

When Aros adds a volume it should check if the volume name already exists, if so it should append a prefix number. But it seems that the volumes are never ejected on Aros but the volume is left behind even though no locks should be in use. Or does Wanderer lock the volume?

Posted on: 2015/5/15 7:10