SFS vs NGFS "PROGDIR:/" question

This forum is for general developer support questions.

SFS vs NGFS "PROGDIR:/" question

Postby kas1e » Wed Dec 26, 2018 10:45 pm

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.
kas1e
Beta Tester
Beta Tester
 
Posts: 482
Joined: Sat Jun 18, 2011 8:56 am

Re: SFS vs NGFS "PROGDIR:/" question

Postby Rigo » Wed Dec 26, 2018 10:58 pm

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
Rigo
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 342
Joined: Mon Jan 17, 2011 10:42 pm

Re: SFS vs NGFS "PROGDIR:/" question

Postby tonyw » Wed Dec 26, 2018 11:50 pm

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
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 1391
Joined: Wed Mar 09, 2011 2:36 pm
Location: Sydney, Australia

Re: SFS vs NGFS "PROGDIR:/" question

Postby colinw » Thu Dec 27, 2018 5:13 am

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
colinw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 180
Joined: Mon Aug 15, 2011 10:20 am
Location: Brisbane, QLD. Australia.

Re: SFS vs NGFS "PROGDIR:/" question

Postby salass00 » Thu Dec 27, 2018 12:01 pm

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
salass00
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 516
Joined: Sat Jun 18, 2011 4:12 pm
Location: Finland

Re: SFS vs NGFS "PROGDIR:/" question

Postby nbache » Thu Dec 27, 2018 12:48 pm

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
User avatar
nbache
Beta Tester
Beta Tester
 
Posts: 1395
Joined: Mon Dec 20, 2010 8:25 pm
Location: Copenhagen, Denmark

Re: SFS vs NGFS "PROGDIR:/" question

Postby kas1e » Thu Dec 27, 2018 5:00 pm

@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) ?
kas1e
Beta Tester
Beta Tester
 
Posts: 482
Joined: Sat Jun 18, 2011 8:56 am

Re: SFS vs NGFS "PROGDIR:/" question

Postby Raziel » Thu Dec 27, 2018 8:28 pm

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...
If slaughterhouses had glass walls, everyone would be a vegetarian. ~ Sir Paul McCartney
-
Did everything just taste purple for a second? ~ Philip J. Fry
-
Ain't got no cash, ain't got no style, ladies vomit when I smile. ~ Dr. John Zoidberg
User avatar
Raziel
 
Posts: 927
Joined: Sat Jun 18, 2011 5:00 pm
Location: a story that hasn't been written yet

Re: SFS vs NGFS "PROGDIR:/" question

Postby tonyw » Thu Dec 27, 2018 11:12 pm

@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
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
 
Posts: 1391
Joined: Wed Mar 09, 2011 2:36 pm
Location: Sydney, Australia

Re: SFS vs NGFS "PROGDIR:/" question

Postby kas1e » Thu Dec 27, 2018 11:47 pm

@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.
kas1e
Beta Tester
Beta Tester
 
Posts: 482
Joined: Sat Jun 18, 2011 8:56 am

Next

Return to General Developer Support

Who is online

Users browsing this forum: No registered users and 1 guest