Shop OBEX P1 Docs P2 Docs Learn Events
fsrw bug(?): can't open zero-length file — Parallax Forums

fsrw bug(?): can't open zero-length file

mparkmpark Posts: 1,309
edited 2009-06-11 00:35 in Propeller 1
I get error -26 when I use fsrw to open some files of length 0 for writing. This only happens for files created in Windows (via Notepad). If the file was created by fsrw, fsrw opens it no problem.

Also, if I put the SD card into my Windows box and try to copy a zero-length file created by fsrw, I get an error ("The file or directory is corrupted and unreadable").

Apparently, when fsrw creates an empty file, it sets the file's first cluster to $ffff, but when Windows creates an empty file, the first cluster is 0, and fsrw chokes on this (in the freecluster routine).

Right now I'm leaning toward the belief that it's a bug for fsrw to make an empty file's first cluster $ffff and to reject cluster 0 in freecluster, but I'm always ready to be proved wrong.

Perhaps some people can try similar experiments on non-Windows machines.

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2009-06-08 00:35
    From what I remember from my writing-FS-days empty files use 0 which indicates end-of-chain. Even so, $FFFF is not a valid cluster index anyway (IIRC it's some error indicator). So it looks like fsrw requires a quick fix here [noparse]:)[/noparse]
  • rokickirokicki Posts: 1,000
    edited 2009-06-08 01:43
    This is probably a bug in fsrw, but it may not have a quick fix;
    I'm not really anywhere I can work on this at the moment.

    Is it a real problem at the moment?

    Also, $FFFF is a valid end-of-chain indicator. Errors are
    before $FFF8.

    -tom

    Post Edited (rokicki) : 6/8/2009 1:48:31 AM GMT
  • mparkmpark Posts: 1,309
    edited 2009-06-08 15:47
    As far as reading empty files with fsrw, a quick fix is to change the "abort(-26)" to "quit" in freecluster.

    As for it being a real problem, I guess that depends on how much importance you place on fsrw being compatible with Windows. Sure we're just talking about empty files, but they do exist.

    Anyway, it cost me some time to figure out what was going on, but I can work around it now, so I'd call it a real problem but not a real urgent one.
  • localrogerlocalroger Posts: 3,452
    edited 2009-06-08 22:51
    If Windows is pointing the empty file at a cluster and marking the cluster 0, this is a bug in windows.· 0 means the cluster is free, which means it could be claimed by a different file looking to start or extend a chain.· If Windows doesn't choke on these zeroes it probably means the incorrect behavior is mitigated by another incompatible bugfix elsewhere in Windows to make sure the starting cluster you've claimed and think you own in a blank file you're about to extend beyond zero bytes hasn't been claimed by another file.

    Correct FAT behavior is to set the cluster to -1 for the bit width of the FAT entry (all F's) which is the FAT definition for end of chain.· Windows probably does the zeroes to keep blank files from clogging up the FAT with unused clusters, but the behavior is undocumented and incorrect.· Which isn't much of a surprise considering the source.
  • kuronekokuroneko Posts: 3,623
    edited 2009-06-08 23:23
    I think there is a misunderstanding here. An empty file doesn't have a cluster allocated (the only space taken up is the directory entry). Said directory entry has a start cluster entry which is supposed to be 0 (no/empty cluster chain).
  • localrogerlocalroger Posts: 3,452
    edited 2009-06-09 21:16
    kuroneko -- that's not what mpark said it was doing, and if it was doing what you propose, fsrw wouldn't choke on it (I have looked at the code recently, as I'm trying to write a better version of it). I have not looked at any blank files made by windows and can't right now because I'm on vacation away from all my test stuff, but I will definitely test this when I get home in about 7 days.
  • mparkmpark Posts: 1,309
    edited 2009-06-09 21:26
    Kuroneko divined my meaning correctly.
  • kuronekokuroneko Posts: 3,623
    edited 2009-06-10 01:07
    localroger said...
    kuroneko -- that's not what mpark said it was doing, and if it was doing what you propose, fsrw wouldn't choke on it ...
    Yes it would. When you open a file in mode "w" it throws away old data. The start cluster is extracted from direntry[noparse][[/noparse]$1A] (which holds the lower 2 bytes but that's enough for FAT16). It then writes -1 to it (which is wrong if it ends up on disk) and then passes the old value to freeclusters() which in turn can't cope with 0. While the latter is easy to fix (as well as writing 0 instead of -1 for re/write and create) there are still places which extend the cluster chain which would have to made aware of the concept of an empty chain.
  • localrogerlocalroger Posts: 3,452
    edited 2009-06-11 00:35
    kuroneko -- I had not gotten that deep into it because I am totally rewriting that behavior from scratch. I did not realize it was quite that much of a hack. In my implementation I am doing it "right" so the issue does not come up. Writing -1 even to the RAM buffer is just a horribly bad idea that can only lead to mischief.
Sign In or Register to comment.