Re: clarification [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 »

cybergorf

Re: clarification

#44

Home away from home

Quote:

cdimauro wrote:
Quote:

cybergorf wrote:
Problematic charakters:

? # * or any wildcard in dos or unix

We only need to care about AmigaDOS.

If you have a build system on your aros, you will be confronted with a lot of unix oddities - so not using "*" is safer.

Quote:

Quote:
Sure there are a couple more that should not be used as part of a volume name.

We only need to chose one.

How about the underscore "_"

Quote:

Quote:
I dont get it, why it must look so exotic

Only recognizable as a special case treatment.
Quote:
or extreemly short??

Because volume names can be long, so the "adjusted" volume name can exceed the allowed length.

Thisisanamewithonly30character:

Sure the max length needs to be taken into account, but cryptic ASCII signs, which the user does not find on the keyboard, are not improving usability.

Quote:

Quote:
Using the device name with a hint to the original label would be unique and sufficiant, without causing trouble while accessing on cli.

See above. Also pay attention to the fact that volumes can rest locked even when they are extracted by the system. If you insert them again, another clash is introduced and should be handled creating a new special volume name, since there's no way to mark as "unique" a volume.

well, staying locked is an other bad behavior, that should be addressed...

BUT: device-names are generic and should therefor be unique anyways.

Example:
usb-stick with one partition "work".


plugging in           --> device du0: , label work:

plugging out          --> everything unmounts, du0: and work: are gone

plugging in again     --> device du0: , label work:

plugging out but lock --> device du0: , label work: stay in system

plugging in again     --> 1) system recognizes its the same hardware

                             and reconnects with old names

                          2) system does not recognize hardware or can not reconnect:

                                        --> new device du1:

                                        label "work" is already in use, therefore

                                        --> generic temporal label du1_work:



plugging in 2. stick --> device du2: , temporal label du2_work:

Quote:

Adding prefixes or appending suffixes will quickly run out of the maximum allowed length for a volume. Unless an unique id policy is used.

devices already need a unique id police. no need to do this twice.

Quote:

Or "work:" shown as "work/0:".

conflicts with file "0" in drawer "work".

Posted on: 2015/5/16 10:55

Edited by cybergorf on 2015/5/16 11:25:47

cdimauro

Re: clarification

#43

Home away from home

Quote:

cybergorf wrote:
Problematic charakters:

? # * or any wildcard in dos or unix

We only need to care about AmigaDOS.

Quote:

Sure there are a couple more that should not be used as part of a volume name.

We only need to chose one.
Quote:

I dont get it, why it must look so exotic

Only recognizable as a special case treatment.
Quote:

or extreemly short??

Because volume names can be long, so the "adjusted" volume name can exceed the allowed length.
Quote:

Using the device name with a hint to the original label would be unique and sufficiant, without causing trouble while accessing on cli.

See above. Also pay attention to the fact that volumes can rest locked even when they are extracted by the system. If you insert them again, another clash is introduced and should be handled creating a new special volume name, since there's no way to mark as "unique" a volume.

Adding prefixes or appending suffixes will quickly run out of the maximum allowed length for a volume. Unless an unique id policy is used.

Quote:

cybergorf wrote:
After reading some posts again, I figured it might not been clear, what I meant by "renaming" or "lelabeling" in case of volume name duplication.

I did NOT mean a pernanent real renaming of any volume, but a smart way to show a diffenent name for a volume, if the name alredy exists in the system.
Just for the time beeing mounted. Anything permanent would be insane of course!

Absolutely. That was the case.

Quote:

So I shall use "beeing shown as" in future posts.

For example:

A partitition on a usb-stick is labeled "work:" but a partition on the harddisk also labeled "work:" is aready mounted at the time the usb-stick is pluged in.

So "work:" on the stick will be shown as (mounted as) "hu0_work:" and can be reached under that temporal name.

Or "work:" shown as "work/0:".

Posted on: 2015/5/16 10:03

cybergorf

clarification

#42

Home away from home

After reading some posts again, I figured it might not been clear, what I meant by "renaming" or "relabeling" in case of volume label duplication.

I did NOT mean a pernanent real renaming of any volume, but a smart way to show a different label for a volume, if the name alredy exists in the system.
Just for the time beeing mounted. Anything permanent would be insane of course!

So I shall use "beeing shown as" in future posts.

For example:

A partitition on a usb-stick is labeled "work:" but a partition on the harddisk also labeled "work:" is aready mounted at the time the usb-stick is pluged in.

So "work:" on the stick will be shown as (mounted as) "hu0_work:" and can be reached under that temporal name.

Posted on: 2015/5/16 8:34

Edited by cybergorf on 2015/5/16 12:08:02

cybergorf

Re: FAT32 USB stick and fat-handler

#41

Home away from home

Problematic charakters:

? # * or any wildcard in dos or unix
Space - yes its allowed but needs always spaeciel treatment in cli
<< >> < > | - pipe symbols lead to problems also
/ - as mentioned

Sure there are a couple more that should not be used as part of a volume name. I dont get it, why it must look so exotic or extreemly short??
Using the device name with a hint to the original label would be unique and sufficiant, without causing trouble while accessing on cli.

Posted on: 2015/5/16 8:22

Edited by cybergorf on 2015/5/16 8:53:08

cdimauro

Re: FAT32 USB stick and fat-handler

#40

Home away from home

Quote:

magorium wrote:
@cdimauro:
in that case i'm intrigued... where's the unique id coming from ?

Very roughly, just to give an idea on how to implement it:


if volume_name in system.volumes:

    new_volume_name = volume_name + '/' + last_allowed_character_for_filesystem_identifiers

    while True:

        if len(new_volume_name) > filesystem_max_length:

            return magorium.get_next_special_volume_name()

        if new_volume_name in system.volumes:

            # We have already saturated the special volume names for such "digit category".

            # "digit category" = single digit family ids, two digits family ids, etc.

            # We need to go to the next digit category, and search again.

            new_volume_name += last_allowed_character_for_filesystem_identifiers

        else:

            # There's for sure a free entry in this digit category.

            # Let's find it with a simple binary tree algorithm.

            return binary_search_special_volume(new_volume_name)

Quote:

I assumed this would be based on something like serial number (which can be quite too long for normal usage).

Every conflicting volume has it's own "serial number generator", so the length of those special volume names is fairly limited.

Also my algorithm provides the shortest special volume name, because it uses all available characters allowed by a filesystem to generate every "digit" for the serial id.

Let's say that the filesystem characters set have 80 characters available. It means that we can have 80 unique special volume names for each conflicting volume, whose total length is len(base_volume_name) + 2 (one for the special separator + one for the serial number digit). When the system has used 80 special volumes, then it needs to use 2 "digits" for the next ones, so he can generate another 80 * 80 = 6400 special volumes. 80 * 80 * 80 = 512000 special volumes with 3 "digits". And so on.

Is it enough or not?

Quote:

But indeed, the most important would be to be able to distinguish those from 'normal' naming.

It's question of using a special separator, if '/' isn't good. Only that. The rest is solved (see above).

Posted on: 2015/5/15 22:10

magorium

Re: FAT32 USB stick and fat-handler

#39

Home away from home

@cdimauro:
in that case i'm intrigued... where's the unique id coming from ? I assumed this would be based on something like serial number (which can be quite too long for normal usage).

But indeed, the most important would be to be able to distinguish those from 'normal' naming.

Posted on: 2015/5/15 21:34

cdimauro

Re: FAT32 USB stick and fat-handler

#38

Home away from home

Quote:

magorium wrote:
If all else fails because of volume names that are limited in length i think i rather see a list like:
- conflict_001:
- conflict_002:
...
- conflict_nnn:

In case of limited length reached by the solution that I've presented.

Posted on: 2015/5/15 21:25

cdimauro

Re: FAT32 USB stick and fat-handler

#37

Home away from home

Quote:

cybergorf wrote:
Quote:

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.

No.... please, please
don?t put an escape character like "/" anywhere near an ASCII string, if you are not forced to do so by aliens or god.

It was just an example. The problem is that using a valid/allowed character as a separator can lead to new clashes, whereas we know that "/" normally is not allowed as a filesystem identifier.

Do you have another suggestion for such special separator?
Quote:

Followed by a "space"... ok now you are kidding me ... you are, aren't you???

Spaces are allowed on filesystem identifiers. Even on normal volume labels.

Remember that we are talking about a special situation, just to mark duplicated volume names. A space is like any other character which a filesystem can use: why do you want to remove it?

Anyway, a subset of the normal filesystem character set can be selected for this special case.

P.S. We are discussing about details, and not the idea.

Posted on: 2015/5/15 21:23

magorium

Re: FAT32 USB stick and fat-handler

#36

Home away from home

If all else fails because of volume names that are limited in length i think i rather see a list like:
- conflict_001:
- conflict_002:
...
- conflict_nnn:

Posted on: 2015/5/15 21:19

cybergorf

Re: FAT32 USB stick and fat-handler

#35

Home away from home

Quote:

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.

No.... please, please
don?t put an escape character like "/" anywhere near an ASCII string, if you are not forced to do so by aliens or god.

Followed by a "space"... ok now you are kidding me ... you are, aren't you???

Posted on: 2015/5/15 21:00