Would the same deadlock occur if you were using AmigaDOS packets instead of filesysbox vector calls?
Yes, the only difference would be that the process that is now waiting for the filesystem mutex to become available would instead be waiting on a reply to their DOS packets that will never arrive.
Yes, looks nice, but what I meant was: If you e.g. Copy CLONE a file from a local disk to the SFTP mounted disk, or vice versa, will the copy still have the same timestamp as the original had?
Normally in an FTP (and SFTP, IIRC) transfer, the copied/transferred files are written with a fresh timestamp.
Yes, looks nice, but what I meant was: If you e.g. Copy CLONE a file from a local disk to the SFTP mounted disk, or vice versa, will the copy still have the same timestamp as the original had?
Yes, SetDate() is supported so this should work (the FUSE callback for this, utimens(), is already implemented).
Today I've spent most of my time hunting down the reason for a deadlock which happened during some simple stress testing of the file system. The cause seems to be that GetTimezoneAttrsA() calls OpenLocale() at the beginning of the function which causes a deadlock situation if the LocaleBase semaphore is being held by another program which in turn is trying to make a file system call to ssh2-handler (all filesysbox vector calls are mutex protected).
I'd guess that timezone.library will check the Locale on each call as the timezone could change if the locale is changed by the user between calls. Could it cache the locale on opening and use a file notification to update it if locale.prefs gets updated?
I'd guess that timezone.library will check the Locale on each call as the timezone could change if the locale is changed by the user between calls. Could it cache the locale on opening and use a file notification to update it if locale.prefs gets updated?
It does seem like a system fix would be better than a workaround. I wonder if other Amiga filesystems are susceptible to the same deadlock.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Well changing timezone.library to try and fix this doesn't seem reasonable, as it's not really doing anything wrong, so I'm changing filesysbox to handle this.
Instead of calling GetTimezoneAttrs() every time I need to know the GMT offset I will just call it once at SetupFS() and then periodically to update it in case it changes.
Filesysbox is already updated, what remains is doing the same for the file system...
Does it support utf-8 (conversion/reading/writing/displaying)?
Say, does it support reading and writing the correct utf-8 chars when using them from a linux/windows partition?
For now i'm not able to use utf-8 char created dirs/filenames with smbfs from linux/windows side.
If that is possible, i want it badly.
Will it be available from AmiStore, an update or even free?
btw: You smbfs error message means that the server you are trying to comnnect to is expecting a password. i.e. if you want o access a win10 share you MUST set a password on the windows side for the user and use this password to access it. (Bit me too)
Does it support utf-8 (conversion/reading/writing/displaying)?
Say, does it support reading and writing the correct utf-8 chars when using them from a linux/windows partition?
It works exactly the same way as other filesysbox based filesystems (exFATFileSystem, NTFileSystem3G).
Any system for converting back and forth between utf-8 and a user configurable 8-bit charset is going to introduce problems of some sort making it basically not worth the bother.
Quote:
Will it be available from AmiStore, an update or even free?
I've not decided yet, but in any case it will require newer versions of newlib and filesysbox than are available with FE update 1.
Quote:
btw: You smbfs error message means that the server you are trying to comnnect to is expecting a password. i.e. if you want o access a win10 share you MUST set a password on the windows side for the user and use this password to access it.
I use the same username and password as for my Ubuntu login. AFAIK that used to work before.
The GetTimezonAttrs() deadlock is AFAICT now fixed.
I ran the script I used for testing about 20 times and it didn't lock up once (before it used to lock up on the 1st run or in rare cases only on the 2nd run).
Does it support utf-8 (conversion/reading/writing/displaying)?
Say, does it support reading and writing the correct utf-8 chars when using them from a linux/windows partition? Quote:
It works exactly the same way as other filesysbox based filesystems (exFATFileSystem, NTFileSystem3G).
Any system for converting back and forth between utf-8 and a user configurable 8-bit charset is going to introduce problems of some sort making it basically not worth the bother.
Ok, then i might have a problem, as i still have a note lying around saying that "exFAT does not understand/support (german) umlauts". I'm pretty sure i reported that back when i found out, but i'm not sure if i ever got an answer to that.
Are umlaut characters supported (on AmigaOS4 level at least?
If your remote filesystem / filenames are utf-8 encoded, anythin that is not ASCII will cause problems. And I really mean ascii here, not extended ascii / iso-8859-1 etc ie characters with 7bits only.
Safest thing is to name your files with just alphanumeric characters only, and no acents or diacritical marks (or punctuation beyond the . in the file extension)
The following problems are all smbfs related, so if SFTP doesn't have the issue, please dicard
I know this issue...sadly it only rears it's ugly head on AmigaOS.
If i use umlauts on Linux and access it on Windows, it's fine, also vice versa.
If i use umlauts on AmigaOS, i can read/write them on Linux/Windows (they come up wrong, masked with some other characters, sometimes with special chars that do not even display), but NOT the other way round (AmigaOS prevents that), which is simply stupid, as it's a limitation solely on our platform.
Umlauts from Linux/Windows do come up wrong on AmigaOS aswell, up to the point where i couldn't even access files
I *could* rename everything to "ue", ae", "oe", "ss" and so forth, but that shouldn't be needed and i don't really have the time to rename a 50+gig music collection, when it works on every other platform out there...mho.
We need UTF-8 filesystem support. That requires DOS to be updated, and Workbench, and anywhere else filenames are displayed/used. Translating the character set within the filesystem is not the right answer, although it might work as a short-term measure.
ah, well...won't use music from my cloud on the Amiga then.
I renamed all directories and files on my NAS which had non-ascii characters, to safe alternatives (e.g. ø to oe etc.). It took a couple of evenings, but allows me to access them from any platform.
But yeah, I also look forward to this hopefully being solved some time in the future.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
