fusefs-exfat doesn't support chmod and chown

[Ralf van der Enden]

Hello,

I've just finished formatting my external drive to ExFAT on Windows and am in the process of putting files on it from my FreeBSD (9.1-RELEASE) system.

To copy/move files I generally use mc (midnight commander) which gives me the following errors after each transfer:

Cannot chown target file "/media/da0s1/test.mkv"
Function not implemented (78)

and

Cannot chmod target file "/media/da0s1/test.mkv"
Function not implemented (78)

To continue copying files I have to skip both errors first.

When I run chown and chmod from the command line, it works just fine.

I've tested this drive with fusefs-ntfs, which doesn't show these errors after the filecopy.

Best regards,

Ralf van der Enden

[Andrew Nayenko]

Hi,

> To copy/move files I generally use mc (midnight commander) which gives me
> the following errors after each transfer:
>
> Cannot chown target file "/media/da0s1/test.mkv"
>> Function not implemented (78)
>
> and
>
> Cannot chmod target file "/media/da0s1/test.mkv"
>> Function not implemented (78)

Right. Fuse-exfat does not implement chown and chmod because exFAT
filesystem does not support access rights.

> When I run chown and chmod from the command line, it works just fine.

Maybe they just don't print an error message when chmod() or chown()
returns ENOSYS?

> I've tested this drive with fusefs-ntfs, which doesn't show these errors
> after the filecopy.

No surprise here. Ntfs-3g supports access rights and implements chown
and chmod.

--
Andrew Nayenko <res...@gmail.com>

[Ralf van der Enden]

Hi Andrew,

I've tested your patch and it works like a charm.

Since I don't have any FAT32 usb sticks lying around I cannot test that.

Best regards,

Ralf van der Enden

PS: I replied the 26th already, but for some reason that mail didn't make it to this list. So sorry for the late reply.

[Andrew Nayenko]

Hi Ralf,

I've seen your e-mail. I've already checked myself (the forgotten taste
of Norton Commander...). MC 4.8.7 emits the same errors when copying
files to FAT32 volume. But there is a "Preserve attributes" checkbox in
copying dialog that may be used as a workaround.

>> Andrew Nayenko <res...@gmail.com <javascript:>>
>>
>

--
Andrew Nayenko <res...@gmail.com>

[david]

Hello,

I can't see the said patch from the this googlegroup discussion thread.

I just submitted a similar patch to the debian maintainer of your fs (v0.9.7), which silently ignores chmod and chown assaults.

My primary goal was to get rid of the annoying behaviour of midnight-commander (and potentially other overdoing it file-managers too).

If one uses an exfat fs, it is known that he can't change anything in permissions and owners. So why not silently ignoring all such requests ?

For my particular uses, it makes life much much easier with midnight-commander.

So I just checked your sources in ubuntu's PPA and noticed that you implemented that functionality in v1.0.1, but only for chmod, and only for OSX.

Why not chown too, and why not for everybody ?

Anyway thanks for this free exfat implementation !

david

[Andrew Nayenko]

Hi,

> My primary goal was to get rid of the annoying behaviour of midnight-commander (and potentially other overdoing it file-managers too).
> If one uses an exfat fs, it is known that he can't change anything in permissions and owners. So why not silently ignoring all such requests ?
> For my particular uses, it makes life much much easier with midnight-commander.
>
> So I just checked your sources in ubuntu's PPA and noticed that you implemented that functionality in v1.0.1, but only for chmod, and only for OSX.
>
> Why not chown too, and why not for everybody ?

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>

[david gauchard]

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

[Andrew Nayenko]

> we can't ask authors to modify their code because of the exfat
> implementation that can't honor some fs-flags

Well, I have to agree.

> 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 ?

After some doubts I've implemented Linux's VFAT behavior but without
"quiet" option support. So now fuse-exfat will allow (for all platforms)
chmod() that changes lower 9 bits of mode and chown() that changes
owner/group to the same owner/group. Is this OK for your scenarios?

--
Andrew Nayenko <res...@gmail.com>

[david gauchard]

Is this OK for your scenarios?

I must say Yes.

Thanks alot.

[mi...@mihaic.ro]

On Saturday, April 20, 2013 12:40:30 PM UTC+2, Andrew Nayenko wrote:

> we can't ask authors to modify their code because of the exfat
> implementation that can't honor some fs-flags

Well, I have to agree.

Could you please also do something about mkstemp? I have to change my normal rsync scripts so as not to use the -a flag, otherwise no data gets transferred.

[Andrew Nayenko]

>>> we can't ask authors to modify their code because of the exfat
>>> implementation that can't honor some fs-flags
>>
>> Well, I have to agree.
>>
>
> Could you please also do something about mkstemp? I have to change my
> normal rsync scripts so as not to use the -a flag, otherwise no data gets
> transferred.

What's wrong with mkstemp()? Could you provide a test case?

--
Andrew Nayenko <res...@gmail.com>

[Mihai Capotă]

Sure (the problem was mentioned by David in this thread):
$ touch test
$ rsync -av test /media/microsd16/
sending incremental file list
test
rsync: mkstemp "/media/microsd16/.test.atUzyd" failed: Function not
implemented (38)

sent 83 bytes received 31 bytes 228.00 bytes/sec
total size is 0 speedup is 0.00
rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1070) [sender=3.0.9]

This works:
$ rsync -v test /media/microsd16/
test

sent 64 bytes received 31 bytes 190.00 bytes/sec
total size is 0 speedup is 0.00

[Andrew Nayenko]

Please try latest trunk. It should be fixed.

Note that user/group changing is not supported anyways. So if you wish
to suppress chown/chgrp warnings from rsync use gid and uid mount options.

--
Andrew Nayenko <res...@gmail.com>

[Mihai Capotă]

On Thu, Jun 27, 2013 at 11:12 PM, Andrew Nayenko <res...@gmail.com> wrote:
> Please try latest trunk. It should be fixed.

It is indeed fixed. I was using version 1.0.1 from the Ubuntu PPA.

> Note that user/group changing is not supported anyways. So if you wish to
> suppress chown/chgrp warnings from rsync use gid and uid mount options.

Thanks for the tip.

[alain....@dexto.ca]

I wish to install this new version of exfat_fuse on a raspberry pi.

It is not available from the apt-get utility but it is available from https://packages.debian.org/wheezy-backports/exfat-fuse repo.

How should I proceed and what are the risk of this task ? 

[alain....@dexto.ca]

Ok, got the answer from different sites:

Raspberry( armhf architecture): https://packages.debian.org/wheezy-backports/armhf/exfat-fuse/download

Although this can be installed, it is not considered stable.

[Andrew Nayenko]

Hi,

I'm not competent enough in Debian packaging. Just want to recommend
using version 1.1 (instead of 1.0.1) which has a lot of bugs fixed. None
of them is critical though.

--
Andrew Nayenko <res...@gmail.com>

[david gauchard]

If still needed,

I've repackaged the debian maintainer sources for jessie (1.1.0) for raspbian.

http://unixrox.net:81/debian/dists/pool/exfat-fuse_1.1.0-2bpo_armhf.deb

(bpo is for "backport only")

credits go to Sven Hoexter, the debian maintainer of this package,

and of course Andrew.

[Alain Lavoie]

Still on wheezy for now, thanks

--
You received this message because you are subscribed to a topic in the Google Groups "exFAT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/exfat/vqPCwJnA_Fo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to exfat+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[david gauchard]

its the jessie source package recompiled for wheezy.
i mean by that that it's a clean debian rule of thumb package.
you can try it on you wheezy rpi.

[alain....@dexto.ca]

Ok, (1.0.1-1~bpo70+1 was not mounting the external drive) so installed exfat-fuse_1.1.0-2bpo_armhf.deb... So far so good... works for now.

Thanks.