SFS errors out of the blue

[AMC258]

Precisely why the decimal point should not be used for that convention.  Nor the comma for the same reason.

Commodore got it right twice:  2.04 and 2.05 :-)

[Piru]

Commodore got it right twice: 2.04 and 2.05

Those were the "marketing" version numbers for the releases. Internally they were WB 37.67, KS 37.175 and WB 37.71/37.72, KS 37.299, 37.300, 37.350.

Probably the name with 0 was chosen so that release 2.1 would not appear "older" than the previous releases, though logically it should have been 2.10 then.

Ultimately this version sheme was set in stone by Commodore with the c:Version command. It interprets the numbers separately, rather than a decimal number. It's easy to test with couple of text files with $VER: tags.

[AMC258]

I still use the zero padding because it works either way and can be read either way.

[itix]

I've never had problems with SFS up until now, but I'll give PFS a try anyway. I'm having problems getting my system partition backed up as it keeps saying certain files can't be found. They're all in the iBrowse cache drawer so I might have to copy everything individually and leave that drawer out.

You can hide damaged directories using SFSobject. Hidden directories are not copied making backup operation somewhat easier.
 

[alexh]

motorollin wrote:
@AMC258
That makes more sense. 1.277 is not bigger than 1.58 in decimal.

Not how it works. First number is the major release number and the second number is the minor release number. See it more as Version 1, build 227.

Dont worry, you're not the first non-programmer to make this mistake, poor Ralph Babel used to get questions about this all the time 4.5 vs 4.15 on his GVP ROM.

http://babel.de/amiga.html

I think the version numbering scheme comes from some version control software similar to CVS or something?!

[itix]

SFS works 100% fine for me, including IBrowse. Anyone complaining about it probably was just unlucky and didn't have a backup. That or their HD is bad...

In fact when talking about software compatibility SFS (Strohmayer version) is not 100% compatible with existing software. It lacks DOS packet compatibility rendering some software (Diavolo Backup for example) useless.

[itix]

Hmm not according to this page:

http://www.xs4all.nl/~hjohn/SFS/download.htm

Is this a different SmartFileSystem? Or has someone else taken over development?

There are four flavours of SmartFileSystem.

The original SFS was developed by John Hendrikx and the last version from him was 1.84 IIRC.

Then there exist newer SFS from Joerg Strohmyaer for M68k and OS4, MorphOS SFS and AROS SFS. All versions are bit different.

[AMC258]

lacks DOS packet compatibility rendering some software (Diavolo Backup for example) useless.

I've been using Diavolo every day with no problems...  What am I doing different?

[itix]

You probably are not using Packet I/O.

[ChrisH]

@adolescent

I have had the same SFS problem with IBrowse that Harry mentions

Did either you or Harry report this to the author of SFS?  If not, he can't look to see if this is a real bug with SFS, or some other issue.  (I suspect "some other issue" but guessing what is rather tricky.)

[Piru]

@ChrisH

Did either you or Harry report this

This problem has been there for years.

And only SFS bombs like this. As soon as the cache is moved to FFS or PFS3, the problem goes away.

[ChrisH]

@Piru
I'll take that as a "no" then.  (It may have been there for you & maybe a few others for years, but if it isn't reported then it can't be known about or fixed by the author...)

BTW, yes it *could* be a bug in SFS, but the fact it isn't seen by many people suggests that it is in some wierd interaction between certain software (or hardware drivers) & SFS+IBrowse.  Both OS3 & IBrowse have many bugs, but these bugs don't usually cause problems - but perhaps SFS does something unusual that happens to be interfered by one of these bugs?  It would not be the first time that a bug in one app is blamed on another...  Maybe SFS has an unusual memory allocation pattern, and that badly interacts with a memory corruption bug in IBrowse?...  Who knows!

[Piru]

@ChrisH

All other things being equal, the simplest solution is the best.

SFS developers (whoever they might be these days) are well aware of SFS bombing pretty much frequently. So much, it's even considered a feature of the filesystem. There are procedures to "resolve" the filesystem corruption (copy data over, format, copy data back).

[ChrisH]

So much, it's even considered a feature of the filesystem.

Don't be ridiculous:  Journaling filing systems are designed to handle unexpected hardware/software shutdowns/crashes in general (not cause them).

But if SFS has a suggested procedure for recovering a corrupted partition, that is because it still has a "beta" tag (which IMHO has not been necessary for a long time, but I'm not the one dealing with other people's precious data).

[Piru]

@ChrisH

Journaling filing systems are designed to handle unexpected hardware/software shutdowns/crashes in general (not cause them).

Journaling does not help against the filesystem corrupting itself. That's why it hardly ever helps to reboot after you get one of the infamous SFS error requesters...

[MickJT]

(Deleted.. Didn't realise it had been discussed to death)