Yes, silly_rename on the directory. Though it is ugly, this startegy
gives good inode number behavior.
The only other idea that came close used the first cluster and
preallocated a cluster every time an empty file is encountered.
This is worse than the above: allocate on stat() just in case
someone opens the file, and use a timeout to deallocate again!
I'll take silly_rename over that for sure.
> FAT doesn't have hardlinks, so...
Umsdos has problems there with hardlinks.
>> The NFS solution is better, and it keeps the same inode number.
>> It also reduces the time during which a crash would leave lost
>> clusters in the FAT.
>
> You'll get bloody unpleasant rmdir with that startegy. And lots of
> nasty code (look through fs/nfs/dir.c for silly_rename() and friends).
It would not be so bad. No other machine will crash or delete
the renamed files.
>> I note that Linux does not currently support the dirty flag:
>>
>> Field Offset Length
>> Physical Drive Number 36 1
>> Current Head 37 1 <--- now a dirty flag
>> Signature 38 1
>> ID 39 4
>> Volume Label 43 11
>> System ID 54 8
>
> Albert, while we might do so we also have MSDOS on hands. What
> will it do with plain, old, boring DOS 3.30?
I doubt it is a problem. If it is a problem, nobody will care.
If by some odd chance this matters, the flag can still be supported
for all filesystems mounted as vfat. (and for all FAT32 filesystems,
but those should always be mounted vfat anyway)
So, does anybody actually using DOS 3.3 want to test this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/