SFS vs NGFS "PROGDIR:/" question

This forum is for general developer support questions.
kas1e
Beta Tester
Beta Tester
Posts: 482
Joined: Sat Jun 18, 2011 7:56 am
Contact:

SFS vs NGFS "PROGDIR:/" question

Post by kas1e »

Found lately, that with NFGS or RAM: i can open file via:
PROGDIR:/test.txt
While with SFS 1.293 can't.

Question is: is it bug in SFS, or its bug in code and it's just feature of NGFS/RAM and all new filesystems in compare with old ones ?

What i mean is that slash thing after PROGDIR: and before file, which make it works on new filesystems, but didn't on old ones such as SFS.

User avatar
Rigo
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 344
Joined: Mon Jan 17, 2011 9:42 pm

Re: SFS vs NGFS "PROGDIR:/" question

Post by Rigo »

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

User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1406
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: SFS vs NGFS "PROGDIR:/" question

Post by tonyw »

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.
cheers
tony

User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 181
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: SFS vs NGFS "PROGDIR:/" question

Post by colinw »

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.

User avatar
salass00
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 516
Joined: Sat Jun 18, 2011 3:12 pm
Location: Finland
Contact:

Re: SFS vs NGFS "PROGDIR:/" question

Post by salass00 »

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.

User avatar
nbache
Beta Tester
Beta Tester
Posts: 1412
Joined: Mon Dec 20, 2010 7:25 pm
Location: Copenhagen, Denmark
Contact:

Re: SFS vs NGFS "PROGDIR:/" question

Post by nbache »

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?

Best regards,

Niels

kas1e
Beta Tester
Beta Tester
Posts: 482
Joined: Sat Jun 18, 2011 7:56 am
Contact:

Re: SFS vs NGFS "PROGDIR:/" question

Post by kas1e »

@all

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:

blocksize: 1024
buffers: 600
MaxTransfer: 7FFFFFFF
Mask: FFFFFFFE

Maybe for SFS2 something like buffers should be bigger (or lower) ?

User avatar
Raziel
Posts: 927
Joined: Sat Jun 18, 2011 4:00 pm
Location: a dying planet

Re: SFS vs NGFS "PROGDIR:/" question

Post by Raziel »

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

User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1406
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: SFS vs NGFS "PROGDIR:/" question

Post by tonyw »

@Raziel:

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.
cheers
tony

kas1e
Beta Tester
Beta Tester
Posts: 482
Joined: Sat Jun 18, 2011 7:56 am
Contact:

Re: SFS vs NGFS "PROGDIR:/" question

Post by kas1e »

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

Post Reply