Finder (it's OS X default file manager) fails to copy files if chmod()
is not implemented, but works fine without chown().
Linux is a different story. Here it is perfectly OK not to have
chmod()/chown() handlers and there are filesystems without them (e.g.
vfat). I think the right way is to fix Midnight Commander to work
properly with such filesystems.
--
Andrew Nayenko <res...@gmail.com>
Thanks,
I understand your answer, and your concerns about replying
to syscalls with what is real. chown and chmod are not possible
nor implemented in exfat design so that should effectively be the
right answer to return to callers.
I still would like to get your attention with several facts.
Not only midnight-commander that I regularly use tries to verify
their operations, there are others (I read nautilus on some threads).
rsync does not work too (it uses mkstemp which fails then complains
and delete it _after_ having written the whole file :-)
The argument about OSX's finder is not fair ! It is not because we can't
ask apple to modify their code that they should be the only one who
benefit from the feature I'm wishing.
Same goes to mc or rsync and others, we can't ask authors to modify
their code because of the exfat implementation that can't honor some
fs-flags. Even if there be an application-side option to ignore the error,
it would imply that the option should be turned on and off everytime
exfat is used.
exfat is a fat/vfat extension which suffers from the same limitations
about flags and permissions. Those who use these filesystems are
aware of that, and do not wish to be limited by regular application
behavior.
I dived into linux vfat implementation for this matter. Correct me
if I'm wrong, but it silently ignores chmod (search FAT_VALID_MODE
in fs/fat/file.c), and optionally ignores chown if the fs is mounted with
'-o quiet' option.
Would it be fair to believe that the same behavior could apply to exfat ?
<joking
Please, I do not want a laptop to be able to use mc,
and apple don't sell mac-pro anymore :)
/>
--
david