Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 20 Nov 2017 14:22:15 -0600
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-fs@freebsd.org
Subject:   Re: MSDOS Filesystem question related to "read-only" files
Message-ID:  <501b5bca-a4b0-7bd9-c1bd-09de0394e136@denninger.net>
In-Reply-To: <0e31a0cf-8a97-1d63-8ebb-9c61d22539cb@denninger.net>
References:  <f4ccb904-63fd-4641-89c8-09357fbb5a1c@denninger.net> <CAG6CVpUZumZaU9xVcri1Ry8=C6j6JrjX5F6qd3oKatYZXFu6Kg@mail.gmail.com> <e6a682a1-322e-a677-3d5e-0a7a503ebd40@denninger.net> <0e31a0cf-8a97-1d63-8ebb-9c61d22539cb@denninger.net>
index | next in thread | previous in thread | raw e-mail 

[-- Attachment #1 --]
Oh, here's another interesting anomaly -- MSDOS filesystems return "0"
for the free file count!

(gdb) print fsbuf
$3 = {f_version = 537068824, f_type = 50, f_flags = 4096, f_bsize = 4096,
  f_iosize = 4096, f_blocks = 1949442, f_bfree = 1949436, f_bavail =
1949436,
  f_files = 0, f_ffree = 0, f_syncwrites = 3, f_asyncwrites = 5,
  f_syncreads = 1907, f_asyncreads = 0, f_spare = 0xbf3fd628, f_namemax
= 255,
  f_owner = 0, f_fsid = {val = 0xbf3fd680}, f_charspare = 0xbf3fd688 "",
  f_fstypename = 0xbf3fd6d8 "msdosfs",
  f_mntfromname = 0xbf3fd6e8 "/dev/da0s1", f_mntonname = 0xbf3fd740 "/mnt"}

Needless to say that can cause some interesting issues if you're coding
to avoid potential inode exhaustion and the target is a MSDOS
filesystem..... FAT filesystems DO have a maximum file count, incidentally.

On 11/20/2017 14:08, Karl Denninger wrote:
> Oh, my apologies -- I didn't include the version:
>
> FreeBSD 11.0-STABLE #0 r313159M: Fri Feb  3 09:58:35 CST 2017
>
> On an RPI2, but I doubt that matters.
>
>
> On 11/20/2017 14:02, Karl Denninger wrote:
>> root@Test-MCP:/home/karl/HD-MCP # cd /mnt
>> root@Test-MCP:/mnt # mount
>> /dev/ufs/rootfs on / (ufs, local, noatime, soft-updates, nfsv4acls)
>> devfs on /dev (devfs, local)
>> tmpfs on /tmp (tmpfs, local)
>> /dev/da0s1 on /mnt (msdosfs, local)
>> root@Test-MCP:/mnt # ls -al
>> total 408
>> drwxr-xr-x   1 hdmcp  wheel    4096 Jan  1  1980 .
>> drwxr-xr-x  20 root   wheel     512 Nov 20 16:04 ..
>> drwxr-xr-x   1 hdmcp  wheel    4096 Nov 19 11:20 System Volume Information
>> -rwxr-xr-x   1 hdmcp  wheel  127979 Nov 19 22:54
>> cam2-2017-11-19-22-54-47.jpg
>> -rwxr-xr-x   1 hdmcp  wheel  271295 Nov 19 22:57
>> cam2-2017-11-19-22-57-20.jpg
>> root@Test-MCP:/mnt # chmod u-w *
>> root@Test-MCP:/mnt # ls -al
>> total 408
>> drwxr-xr-x   1 hdmcp  wheel    4096 Jan  1  1980 .
>> drwxr-xr-x  20 root   wheel     512 Nov 20 16:04 ..
>> drwxr-xr-x   1 hdmcp  wheel    4096 Nov 19 11:20 System Volume Information
>> -rwxr-xr-x   1 hdmcp  wheel  127979 Nov 19 22:54
>> cam2-2017-11-19-22-54-47.jpg
>> -rwxr-xr-x   1 hdmcp  wheel  271295 Nov 19 22:57
>> cam2-2017-11-19-22-57-20.jpg
>> root@Test-MCP:/mnt #
>>
>> Nope.  The "w" is still there.
>>
>> No error returned from the "chmod" command (or if I call it from a C
>> program) but the file mode is NOT changed whether I'm doing it as the
>> superuser or as the owner of the file (and directory)
>>
>> On 11/20/2017 12:30, Conrad Meyer wrote:
>>> Hi Karl,
>>>
>>> In fact, msdosfs in FreeBSD should set the FAT READONLY attribute
>>> under two conditions:
>>>
>>> 1. The owner chmod's the file non-writeable (chmod u-w) (what you've
>>> described, I think).  Or,
>>> 2. The super user or otherwise privileged user sets the "readonly"
>>> flag on the file via chflags(1).
>>>
>>> How have you determined that chmod u-w does nothing?  What version of
>>> FreeBSD are you using?
>>>
>>> Best,
>>> Conrad
>>>
>>>
>>> On Mon, Nov 20, 2017 at 7:36 AM, Karl Denninger <karl@denninger.net> wrote:
>>>> I'm running into an interesting issue here and wondering if there's a
>>>> way to do this under FreeBSD.
>>>>
>>>> MSDOS filesystems have a "primitive" permission capability;
>>>> specifically, they can have a "Read-only" attribute on a file.  It looks
>>>> like OpenBSD supports this from reading their man pages.
>>>>
>>>> FreeBSD doesn't appear to.  When you mount a msdos filesystem (e.g. a
>>>> USB stick) whoever owns the parent directory where you mount it gives
>>>> you the permissions and "ownership" of files on said filesystem.  All
>>>> good so far.  But attempting to chmod a file to remove write permission
>>>> "succeeds" (returns success) but does nothing.
>>>>
>>>> Is this capability simply not present on FreeBSD?  I'm interested in
>>>> using it as a means of "flagging" files on a USB stick in an application
>>>> that I do not want to remove if the stick fills (basically, to "protect"
>>>> them from being aged off) and it appears there's no way to do it, other
>>>> than to use something unique in the filename that I would then have to
>>>> pay attention to.
>>>>
>>>> --
>>>> Karl Denninger
>>>> karl@denninger.net <mailto:karl@denninger.net>
>>>> /The Market Ticker/
>>>> /[S/MIME encrypted email preferred]/

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H

00H^Ōc!5
H0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CA0
170817164217Z
270815164217Z0{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CA0"0
	*H
0
h-5B>[;olӴ0~͎O9}9Ye*$g!ukvʶLzN`jL>MD'7U45CB+kY`bd~b*c3Ny-78ju]9HeuέsӬDؽmgwER?&UURj'}9nWD i`XcbGz\gG=u%\Oi13ߝ4
K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏNTa(25DD5.l<g[[ZarQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ!}ș+2k/bųE,n当ꖛ\(8WV8	d]b	yXw	܊:I39
00U]^§Q\ӎ0U#0T039N0b010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CA	@Ui0U00U0
	*H
:P U!>vJnio-#ן]WyujǑR̀Q
nƇ!GѦFg\yLxgw=OPycehf[}ܷ['4ڝ\[p6\o.B&JF"ZC{;*o*mcCcLY߾`
t*S!񫶭(`]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@jެEgl
)0JG`%k35PaC?σ
׳HEt}!P㏏%*BxbQwaKG$6h¦Mve;[o-Iی&
I,Tcߎ#t wPA@l0P+KXBպT	zGv;NcI3&JĬUPNa?/%W6G۟N000k#Xd\=0
	*H
0{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CA0
170817212120Z
220816212120Z0W10	UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
	*H
0
T[I-ΆϏdn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~_KPn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr>е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5	dDB7k-)9Izs-JAv
J6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@y]}6ٽeY9Y2xˆ$T=eCǺǵbn֛{j|@LLt1[Dk5:$=	`	M00<+00.0,+0 http://ocsp.cudasystems.net:88880	U00	`HB0U0U%0++03	`HB
&$OpenSSL Generated Client Certificate0U%՞V=؁;bzQ0U#0]^§Q\ӎϡ010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CAH^Ōc!5
H0U0karl@denninger.net0
	*H
۠A0-j%--$%g2#ޡ1^>{K+uGEv1ş7Af&b&O;.;A5*U)ND2bF|\=]<sˋL!wrw٧>YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n”} ͬ:{hTP3B.;bU8:Z=^Gw8!k-@xE@i,+'Iᐚ:fhztX7/(hY` O.1}a`%RW^akǂpCAufgDixUTЩ/7}%=jnVZvcF<M=
2^GKH5魉
_O4ެByʈySkw=5@h.0z>
W1000{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0
	`HeE0	*H
	1	*H
0	*H
	1
171120202215Z0O	*H
	1B@<0qy:-(رr}F<6GnF!hػպ %Uws0l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+7100{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0*H
	10{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0
	*H
}`bBir;uqȢ샾;E ?V|~wMLhtjGFڏ|O󷁿	3糦#EI=kzIV3VKQ@TWi(Q85]oHA
leO,Uһ~\C\q{/מ=q۠f`٣D)#"`_ZpC@ߞMSEͳC3n$QD"8tA䂭FM`¬2.ԘVB.]Z*ۭ*'2(F;J4I()ҡ]$s$8κf#0T_bP4_B݇HLi*7O:gp|0A(i>LSUZvlPʔ!IP7A3+xy!-W}	8\\d	ǏUq7	BƟ>Fq\*NW
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?501b5bca-a4b0-7bd9-c1bd-09de0394e136>