Shop OBEX P1 Docs P2 Docs Learn Events
Idiot Protection ^_^ For File System — Parallax Forums

Idiot Protection ^_^ For File System

KyeKye Posts: 2,200
edited 2010-12-24 09:23 in Propeller 1
Hey Everybody!

I'm getting close to publishing a new FAT16/32 file system driver called the SD3.0_FATEngine.

It is significantly better than the SD2.0_FATEngine in both speed and usability. (If you want to ask questions about it I will answer them and take suggestions also).

---

Anyway, I'm starting this thread first off to get input on what I should do about open file locking. Here's my problem:

Function A opens a file and does some stuff with it.
Function B then deletes or moves the open file... BAD!!!

Operating systems usually maintain a list of the open files to prevent this kind of stuff from happening. But on the propeller I cannot do this. This is because I do not want to use dynamic memory.

Each included version of my file system driver allows for 1 file to be open. This means you can have as many files as you include the driver. I could over come this locking problem by making it so that you could only have a set number of files open... but I dislike the compromise.

So, my question is... should I just not fix this problem and let the user "eat it" when they do operations as described above? Or should I implment an imperfect solution to this problem that is only caused when the user does something stupid? I disklike both choices... but I gotta choose one.

Comments

  • kwinnkwinn Posts: 8,697
    edited 2010-12-22 19:17
    Normally when a file is opened by a program or function as read/write other functions can only open the same file as read only. Is this not a possible option?
  • lonesocklonesock Posts: 917
    edited 2010-12-22 19:23
    Maybe something like this?

    * Only one file is open for write at a time (use a lock)
    * as many files open for read as desired
    * the read files may not be the write file (and vice versa)
    * store the name of the write file (or NULL if none) in the block driver (as I assume you are sharing it [8^)

    How fast is 3.0, reading and writing, for a single file, sequential access (assume maximum cluster size)?

    Jonathan
  • MacTuxLinMacTuxLin Posts: 821
    edited 2010-12-22 20:18
    Hi Kye,

    First off, thank you for the SD2.0 FATEngine.

    As for your question, it does not seems to affect my project either way but let me explain how I'm using your driver. I wrote a sort of SD controller, that calls SD2.0FATEngine, which allows different modules to have work on the same file but on different segment of the file. Does locking in your new driver affect such operation in any way?
  • AleAle Posts: 2,363
    edited 2010-12-23 01:40
    In the unix world you can "overwrite" a file and nothing happens because the old file is not overwritten at all, just the entry in the directory is reused, a new file is created and the old file, the block allocated for it, are freed once the process that has it closes it :)... nice. Sorry for the off-topic :)
  • KyeKye Posts: 2,200
    edited 2010-12-23 10:08
    Ah, that's for your replies but I'm really asking for a solution from anyone who has ever written an operating system...

    See, the probem is that if I share a memory buffer between different instances of the FATEngine I force myself then to have a maximum number of files open equal to the size of that memory buffer.

    ---

    I think I found a solution however to the problem.

    First, only 4 files open at once will be supported. Each instance of the FATEnigne will support one file. So you can include the driver as man times as you'd like but the maximum number of files that can be opened will be 4.

    Whenever a file is opened I save the absolute raw disk sector of the start of that file in a buffer.

    Whenever anything is done to a file... including opening one... I look through the buffer (mentioned above) for that file to see if it's locked open. If its found in the buffer I throw an error.

    This will prevent problems from occuring. But, it limits me to a maximum of four files. My original question was should I include this locking feature at all to prevent improper access. As long as you were doing this in the correct way you would not have a problem first off... Mmm, but I guess I have to put the idiot protection it.

    ---

    @MaxTuxLin - Locking support in my new code works correctly. The whole FS is locked whenever a function it it is called. So only one thread can be in it at a time. I don't know what sort of problems this may cause for you.

    @lonesock - My driver still is MUCH slower than yours. I only hit the original FSRW speed. But that's good enough for me. I haven't been able to test the speed preformance in a while since I've been working on other parts of the system. About to get to the file part soon however.
  • SapiehaSapieha Posts: 2,964
    edited 2010-12-23 10:18
    Hi Kye

    Why NOT only save FILE NAME and OPEN type W/R else R as flag to that name.
    As In all systems only one instance can have file opened for Writing.
  • KyeKye Posts: 2,200
    edited 2010-12-23 11:02
    Because you're allowed to have directories and multiple partitions.

    So, a file name is not helpful. Because it could be the file name on another partition or in another directory.
  • SapiehaSapieha Posts: 2,964
    edited 2010-12-23 11:04
    Hi Kye

    All systems SAVE entire Patch to that file and test for
  • KyeKye Posts: 2,200
    edited 2010-12-23 16:57
    That would be overkill. Saving the absolute secotr start address will work much better.
  • potatoheadpotatohead Posts: 10,261
    edited 2010-12-23 20:48
    Kye, can it be solved at the file system level?

    Just create a .lck file that the driver looks for before doing anything with a given file. If it's present, access denied. There is the problem of a crash leaving the .lck file, but then again, it's not a hard fix. Users can easily use a PC, or author a little utility...

    I kind of like the idea of the driver doing what the user tells it to, fast, efficient, easy. Maybe this kind of thing wouldn't break that. Just a thought.

    The new file has the same name as the old one, only with the .lck extension. I can see a extension conflict, where you have file.one, file.two, file.txt. Only one .lck would be permitted... Dang short names. Maybe it won't work without being able to resolve that conflict. Easy to do on bigger name spaces. Not so easy... Maybe have the name of the file contained in the .lck file?

    Ugh...

    No matter how that all goes, I vote for let the user eat it.
  • KyeKye Posts: 2,200
    edited 2010-12-24 09:23
    I don't have todo the .lck file stuff at all. There's space in the DIR File struc to store a bit to lock and unlock a file. The problem with doign that though its that files can get locked open...

    I think having files locked open would cause worse problems. So... that ides is probably out.

    ---

    Yeah, I just want to let the user eat it too.

    Big questions... big questions... no answers...
Sign In or Register to comment.