In the old days, a file system was expected to scan a file path itself, taking out locks on each sub-directory in turn until it came to the destination directory.
These days (with DOS version 53.95++), all the file paths are scanned by DOS, not by the (new) file systems like ram-handler, env-handler and NGFS. The newer file systems are little more than a library of calls to file system primitives, and DOS does most of the work in deciding what will be called. The file system just has to implement the "primitive" calls as in the specification (include_h/dos/filehandler.h) and there are test programs to make sure that the file system obeys the rules. This approach allows the file system programmer to concentrate on the more difficult parts like caching, etc. It also makes the behaviour the same for all (new) file systems.
Older file systems like FFS and SFS have not, and will not, be modified to meet the new criteria.
Yes, Rigo and TonyW are correct.
The new filesystems all get their paths pre-resolved by the V53+ dos.library function ResolvePath().
It resolves all the paths fed to functions that take string input arguments like Lock(), Open() etc...
As TonyW mentioned, previous dospacket based filesystem handlers each had to write their own path
resolver code as the entire string was passed to them, with the new filesystems, only the object name
and the relative directory lock is supplied, so the filesystems no longer need to cook up their own resolver.
This fixes a couple of issues, namely inconsistencies between different filesystem implementations and
the lower code overhead for all new filesystems writers.
Your example of "PROGDIR:/test.txt" is likely one of the inconsistencies when using an unexpected or
somewhat convoluted construct, where in this case the slash after the delimiter character indicates
you want the directory above where PROGDIR: points, to find the file called "test.txt".
Remember, this case would only work if PROGDIR: was not pointing at the root directory.
Rigo wrote:
The fault in SFS is most likely one of the reasons it has been deemed buggy and problematic, and should now be considered obsolete.
It's not really a fault though, as "RAM:/" is not a legal path.
If anything the fact that ResolvePath() allows this and treats "PROGDIR:/test.txt" the same as "PROGDIR:test.txt" in the case where PROGDIR: points to a volume root directory could be considered a bug.
salass00 wrote:It's not really a fault though, as "RAM:/" is not a legal path.
Isn't it, though? It may be a non-existant path, but it's syntactically correct.
If anything the fact that ResolvePath() allows this and treats "PROGDIR:/test.txt" the same as "PROGDIR:test.txt" in the case where PROGDIR: points to a volume root directory could be considered a bug.
I just tested a situation where I have a text file in a root dir, and assign MyTest: to that dir. If I enter "type MyTest:/myText", it correctly says that it doesn't exist. But the tab completion in the Shell "finds" it anyway; if I enter "type MyTest:/my" and hit Tab, it completes it as "MyTest:/myText".
So is this because the type command and the tab completion call two different functions? And should one of them be fixed, so the tab completion won't find the file in the wrong place?
There is another interesting issue i notice. I can't desribe it well in details, but : i have a game, which, when i run on NGFS, runs fine, responsive, and co. But when, i just copied the same archive 1:1 on sfs2 partition, and run it from there, i have some weird little "pauses" when play in game. I.e. like whole resposivity start to be slower. I walk in the game and bah, pause, walk a bit more, bah, pause. Its some microseconds pause, but visually noticable. Files exactly 1:1 the same, its just 2 copies of the same, just one on NGFS, another on SFS. On NGFS all feels smooth, on SFS all a bit "lags" all the time.
Can it be because of some default SFS2 settings ?
I have for both SFS2 and NGFS default settings which give at me MediaToolbox:
Rigo wrote:I would guess the later filesystems have a more robust path scanner.
The fault in SFS is most likely one of the reasons it has been deemed buggy and problematic, and should now be considered obsolete.
Simon
Is that meant to cover only "SFS" and not "SFS2"?
Because if the whole SFS is "buggy and considered obsolete", most of the users (non-beta testers, me included) have a potentially dangerous FS installed...
People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg
No, the bugs are unimportant. They are mainly inconsistencies (SFS does some things differently from other file systems) and missing parts (SFS does not support hard links, for example). I mean both SFS and SFS\2.
@kas1e:
The block size and other variables that can be set in Media Toolbox are ignored by NGFS. NGFS chooses its own block size and cache size ("buffers") to suit the available memory and partition sizes. The user can not change them.
@tony
Yeah, with ngfs all fine.
Its with sfs2 i have some micropauses in game, which i think can be related to blocksize or buffers of sfs partition, so question is i need to change values i have by default for sfs2.