GideonZ
SoftIEC Command cd:<- / cd<-
Referring to the discussion on Messenger.
The SoftIEC command cd<- or cd:<- takes us to the directory defined by the Default Path option.
This seems to be consistently associated with the cd<- command of CMD storage devices. Where it takes us to the root of the partition.
However, the cd:<-name command in CMD takes us to a folder called <-name
This creates an exception.
If it is not planned to maintain compliance with the standard previously introduced by CMD, please ignore the report.
I know that there are already ready-made applications that use the command cd:<- in SoftIEC Which complicates the introduction of some standardization here. This would involve updating this software.
This is a non-critical issue. It does not affect the operation of other programs. It is merely confusing for the user who uses CMD and SoftIEC commands at the same time.
This seems to be consistently associated with the cd<- command of CMD storage devices. Where it takes us to the root of the partition.
No, it takes you one director level up. That is, it changes to the parent directory. Both have checked the manual and tested.
However, the cd:<- command in CMD takes us to a folder called <-
Well, on SD2IEC, »cd:←« is the same as »cd←«. Therefore I think best is to avoid »←« as directory name.. Note we cannot be compatible to both without a configuration setting. And since CMD has not a home or default directory or whatever you call it, we need a syntax to switch to it. Perhaps UNIX like the empty path (I doubt CMD has used the empty path, so that could work).
If it is not planned to maintain compliance with the standard previously introduced by CMD, please ignore the report.
We do want to make it compatible, don't we? For a few things it makes sense to make them configurable.
Which complicates the introduction of some standardization here.
If you consider classic C64 hardware (which includes 1541 speeders), you'll note you cannot be compatible to all of them. I think and that is only my opinion, the best to do is providing a possibiliy to write software that works on all of them. A programmer can always chosse a non compatible command, but there should be no need for him.
In order not to forget it: You change to the root of the partition on CMD devices with »cd//«.
All clear. My mistake. I built a directory structure only for 1 lv. down. Hence, I wrongly assumed that cd< always moves to root.
Yup... we need to differentiate between CD and CP. Does CP also allow paths? Message ID: @.***>
No, "cp" is "change partition" and only accepts a number as parameter. Nothing else. And if you write "cP" (uppercase P), the number is not written in PETSCII, but as binary value. Except that technical difference, "cP" is the same as "cp". CMD partitions are in the sense like "gparted" or "diskpart" or "fdisk"... and there is really a C64 tool tthat creates them.
Okay.. Then how do we define what are the roots of a partition, if the CP command doesn't support a path? How do you specify (programmatically) where the partitions are located in the file system? Message ID: @.***>
Since CMD and IDE64 don't have that concept, I would say: Via file browser of the ultimate. You know I have already started changes which certainly need refactoring. And pretty printing. Like "Set dir. here" already present in F5, ... SoftIEC..., I have added "Set root here". Both open a window where the user enters the partition number to change.
And for partitions 1 to 12, he can also choose "Cfg. root here", which copy the path to the SoftIEC settings. So it is available at poweron. Note we have asked some more or less random users: Most do just use 1 partitions. Other think that 4 to 8 partitions are enough. "Device Manager" needs partition 11 (with "/" as the root and some working directory as default directory). So 12 permanent partitions are probably enough.
Note that this is only one possibility - but one that makes it simple for the user. We can decide to use another user interface if we have a better idea. But it should be a function of the configuration area together with the file manager (to remember and to type in paths are is not very convenient, is it?)
We could also add a command that is not used by any pf the speeders and CMD, IDE64 and SD2IEC. Perhaps "cr" like change root. So that the C64 code can set them.
@radius75 If @GideonZ thinks it will help, I would start soon writing down all commands we should support in an Excel sheet. With comments like path allowed, path necessary or path forbidden. The documentation is quite quiet about where wildcards are supported and if they're supported, whether they affect all files or only the first file found. If you want to help, you can then help to find that out.
Additional option "set default path as root" set to off by default? So that it is impossible to go cd// higher than the user wants. Is this any solution?
That is to be discussed. In my, well I might call it Proof Of Concept, you can combine virtual root (I often call it chroot after the Unix command) and default path.
/path/to/foo/ is a default path with virtual root "/"
/path/to/root// is a default path which equals the virtual root.
/path/to/root//and/within/some/path/ has virtual root »/path/to/root/« and within it »/and/within/some/path/« as a default path. So you just need to adapt the extra slash to change that. Of cause, a UI might give the user the few possibilities to choose from... So that he cannot do it wrong when using the file browser.
Note that this way it does not need really more storage than not having the arbitraty virtual root. So that is space optimized storage of configuration.
Dunno what you and Gideon think, but I like the extra flexibility that this provides.
What about something like an index file? In which you should write the path to each partition. Path to the folder or inside .dnp. 254 records could be saved in such a file, to address partitions 1 to 254 in turn. 254 is the max for CMDHD For CP command
Yes, this is exactly how I discussed it before with Mario. But never got the change to implement it. Making such a file is easy, but making it also user-friendly editable in the menu is a lot harder.
Message ID: @.***>
Menu F5 and 'set partition no. XXX here'? With saving changes to the appropriate record in the index file.
The basic option is 'set partition no. XXX here' and 'delete partition no. XXX' from index. Do you need any additional option for the user? Index as a text file can be viewed with the View option. Apart from path, what other parameters should such a record contain? Maybe the name of the partition for the NEW option, if possible formatting by n:name,id , and some other information. But in this case, an external editor would be better for advanced editing of the index file. Or manually in notepad.
Well, I see two problems with an index file. If we manage to solve them, we can use it, too.
- What if two index files on two USB sticks have conflicting index files and you insert both of them?
- How to create a Partition with root "/Temp"?
Not really a problem to solve: 3) Make sure it works with "/Flash", too. Current device manager makes a »cd:/Flash" and tries to load a file. If this fails, it tries the same from the default directory. Perhaps Bart would like to change it to real partitions with a later release, Or others will do something like that. Better to support that.
Solution proposal for 1. Since there is only one SoftIEC device.
Multiple index files can be stored to run different drives with different sets of partitions. Under different names. e.g. drive1.sys drive2.sys.... or something. (.idx is already provided for TAP files)
But of course not loaded at the same time.
The path to the currently selected index file is manually set in the options. Then this would be the only path needed to enter in the options. All other necessary paths to all selected partitions would be read from the index file.
Basic question Is there anything stopping the selected partitions (saved in idx) from being in different folders, or even on different USB sticks? Some on USB0 and some on USB1?
I assume a text file with at least one path per partition. Extra info in that file as needed.
Then it depends. If the configuration file if defined to contain paths relative to the root of the usb stick, then you cannot leave the usb stick. If the configuration file if defined to contain absolute paths, then you must plug in the usb stick in the right usb connector. If you use the wrong usb connector, e. g. /Usb0 changes to /Usb1.
Both have pros and cons.
One more thing to note: If we don't want to break device manager without a possibility to repar it by asking Bart tto patch device manager: We need the partition configuration being active at power on time. Device manager is an emulated cartridge for the C128 that starts software at power on time.
My initial thought on this, is that the partitions are part of the configuration and should therefore be stored in flash. However, I can also understand that carrying your partitions with you on a USB stick makes this more difficult. My suggestion would be to allow configuration files (probably just JSON) on a USB stick, and make references to paths relative. Thus, when starting with '/', you start from the root of the VFS, without '/' it is relative to the directory in which the configuration files exists. This way you can also refer to /Temp.
An additional thing to consider is conflicting partition numbers. In principle, a configuration file must specify the partition numbers; these cannot be dynamic. Maybe it should be as simple as 'first come first serve'. When a file system is mounted, the config file is loaded from that filesystem, and added to the partition list definition. If the partition number is already taken, it is simply ignored.
Well, I think I have to think about that.
I still prefer having the partion table on the flash. But it might be possible to place that file just into the flash file system as an option. So when done properly, that is no show stopper.
You see, autoload partition tables is also something I have to think about it. Curently I am worried that the following situation might get a problem: I need one file from a different usb stick. So I insert it in order to copy the file from it to let's say /Temp. Well, in that case I would not like that it disturbs my partitions. Partition file always on "/Usb0" resp. "/Flash" would avoid that clearly.
BTW: It's natural to have partitions spread on multiple USB sticks. CMD HD does something similar: It has a SCSI bus where multiple hard disks and similar (like ZIP disk) can be attached. So partitions are spread over multiple data storing devices.
Hmm... I think we misunderstood each other. In particular, I think it does not mess up your partitions. Take for example this config file on /Flash
{ "partitions": [
{ "number": 11,
"path": "/Temp"
} ]
}
This would specify the temp partition on 11. Then, when the USB stick is recognized in port 0, it loads the config file on the root of the USB, which contains:
{ "partitions": [
{ "number": 1,
"path": "SomeDir"
},
{ "number": 2,
"path": "SomeOtherDir"
} ]
}
Then, your partition table would look like this: [ 1: "/Usb0/SomeDir", 2: "/Usb0/SomeOtherDir", 11: "/Temp" ]
When you remove the USB stick, the list of partitions is again updated to: [11: "/Temp"]
Like this you can have multiple USB sticks, with multiple sets of partitions, which are automatically merged.
I see. The point is something different. Is a running C64 program necessarily prepared for partitions disappering?
And is mount time reproducible? If /Usb0 and /Usb1 are connected at poweron, the order seems to be quite random (but not necessarily equally distributed). Having random partitions - well, not the best idea. Would have to avoid that situation.
It doesn't matter. If you have conflicting configurations, you have conflicting configurations. It is not something you should try to solve by being smarter than organized.
I see. The point is something different. Is a running C64 program necessarily prepared for partitions disappearing?
In the same way as programs are prepared for floppies being removed from a disk drive, I guess?
We could even add a priority field in the config file to make it even fancier... to know which one should take preference, if conflicts occur.
Well, if you were using Geos, then you would know that Geos is not prepared for disk changes in most situations. You should change disks inside Geos only when a) Geos ask you to do so b) You're in Desktop and have the Window of the corresponding drive closed.
And on a CMD hard disk, you cannot change disks. Hardware allows SCSI ZIP drives, but changing them is only supported by rebooting the whole CMD HD.
Okay, getting GEOS compatible is something different. Except a special build of Geos Megapatch 3 that is using kernal I/O, Geos uses its own fastloader. While I am pretty sure that there are users that would find a GEOS compatible IEC device fine, I see that it has nothing to do with making it CMD compatible. Really nothing. Geos is AFAIK just using Read Block and Write Block. And Change Partition. No more.
I think you are overcomplicating things. If you have conflicting configurations, you have conflicting configurations. Error out if you wish and that's it. No need for clumsy heuristics. Bail, show a message, so you can fix your issue in a way it should be fixed.
Same for Geos. Geos cannot prevent you from removing a floppy disk. Neither can the ultimate prevent you from removing a USB stick. Once the Usb is removed the files on it cannot be accessed. So this means the files in the removed partitions cannot be accessed.
Probably yes. Perhaps we should just give it a try, Knowing we can improve it at any time. E. g. if it is found that auto adding partitions should be restricted, we can restrict it.
Coming back to "cd<-" for a moment
I looked at how it works on Vice in CMDHD emulation I don't know for sure if we can trust that this emulation behaves like a real device in every case.
cd<- -directory lv up cd:<- -directory lv up (!) cd:<-name -go to directory named <-name
This means that a directory with only <- in its name cannot be accessed with the cd:<- command. (But you can enter in another way)
And the CMD manual doesn't mention anything about it. It doesn't even give an example of using the command this way with a colon.