This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FAT FS questions


Ok, so my plan was to add a chmod function. However, after looking at the was the file system functions are structured, this may not be the simplest solution. Actually it should be pretty easy to add a new function to the fstab_entry list and then to each of the 4 supported file systems. Make the functions just return EINVAL for the file systems which do not support chmod.

My other option would be to add it to the setinfo function. That would "break" less things and decrease "bloat" in the other file systems, but then the corresponding getinfo should return the same info as stat, which would seem a little redundant.

I would actually prefer the first method, but I understand if you would rather me pursue the second. But I figured that I would hold off until I checked to see what the preference was.

Thanks
David Brennan

Andrew Lunn wrote:

y> MS-DOS had a read-only attribute, with no concept of users. Even though the


read-only attribute could be turned off, it was still useful, for preventing
modification or deletion by "normal" code which didn't go to the trouble of
turning it off.



From the DOS world it has a read only bit. But from the POSIX world,
which eCos follows, that has to be mapped into owner, group and other
read, write, execute bits. Its the POSIX in the middle that makes it
complicated. Also you have problems with ".. trouble of turning it
off." Like i said, there is no chmod() so you cannot enable writing
from eCos.

Andrew




-- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]