public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: tridge@samba.org
Cc: sfrench@samba.org, linux-ntfs-dev@lists.sourceforge.net,
	samba-technical@lists.samba.org, aia21@cantab.net,
	hirofumi@mail.parknet.co.jp,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: FAT, NTFS, CIFS and DOS attributes
Date: Mon, 03 Jan 2005 17:14:30 -0800	[thread overview]
Message-ID: <41D9EDF6.1060600@zytor.com> (raw)
In-Reply-To: <16857.59946.683684.231658@samba.org>

tridge@samba.org wrote:
> 
> I think you'll find that all users of dos attributes on Linux will
> have very similar needs to Samba, and will want these things grouped
> together. For example:
> 
>  - backup/restore apps will want to backup/restore these attributes as
>    lumps
>  - wine implements essentially the same APIs as Samba, just in a
>    different form, and so tends to get the same groupings of
>    attributes get/set calls that Samba does (the SMB protocol is to a
>    large degree a on-the-wire version of Win32).
> 
> Are there any other significant users of DOS attributes on Linux that
> want something different?
> 

I don't know, but it certainly doesn't match my application (which is 
pretty simple... needing to frob DOS attribute bits while writing DOS 
files) or expectation thereof... plus it's not very unixy :-/

More or less what you seem to want is an ioctl() that takes a mask of 
what to write, similar to the way notify_change() works inside the 
kernel.  This is a legitimate API, but it requires knowledge of the 
internals, and isn't setxattr().  The big thing here is the need for a mask.

Of course, one way one can do this is to expose user.dos.attrib or 
something like that as a synthesized block form of these, and still have 
separate system.* xattrs that control the individual options on the 
filesystems which actually store this stuff.

I certainly see why *you* want it, but it still seems to me to be bad 
interface design for anything other than backup and file repository 
programs.  Also see my previous note about endianness of structures 
carried from place to place.

At this point I think I'm going to let my ioctl() patch stand as-is, 
solving the immediate problem, and let people who are more directly 
affected delve into this particular morass.

	-hpa

  reply	other threads:[~2005-01-04  1:15 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-03 22:24 FAT, NTFS, CIFS and DOS attributes H. Peter Anvin
2005-01-03 23:26 ` Michael B Allen
2005-01-03 23:33   ` H. Peter Anvin
2005-01-03 23:48     ` Michael B Allen
2005-01-03 23:55       ` H. Peter Anvin
2005-01-04  0:18     ` tridge
2005-01-04  0:24       ` H. Peter Anvin
2005-01-04  0:39         ` tridge
2005-01-04  0:57           ` H. Peter Anvin
2005-01-04  1:12             ` tridge
2005-01-04  1:31         ` Nicholas Miell
2005-01-04  1:48           ` H. Peter Anvin
2005-01-04  2:05             ` Nicholas Miell
2005-01-04 22:24       ` [Linux-NTFS-Dev] " Szakacsits Szabolcs
2005-01-04  1:21   ` tridge
2005-01-04  1:30     ` H. Peter Anvin
2005-01-03 23:28 ` Nicholas Miell
2005-01-04  0:05 ` tridge
2005-01-04  0:30   ` H. Peter Anvin
2005-01-04  0:58     ` tridge
2005-01-04  1:14       ` H. Peter Anvin [this message]
2005-01-04  1:36         ` tridge
2005-01-04  1:50           ` H. Peter Anvin
2005-01-04  2:05             ` tridge
2005-01-04  2:09               ` H. Peter Anvin
2005-01-04  2:23               ` Kyle Moffett
2005-01-04  2:49                 ` tridge
2005-01-04  3:39                   ` Kyle Moffett
2005-01-04  3:56                     ` tridge
2005-01-04  4:50                       ` Kyle Moffett
2005-01-04  4:05     ` Michael B Allen
2005-01-04 10:34 ` Anton Altaparmakov
2005-01-04 11:08   ` Anton Altaparmakov
2005-01-04 22:18   ` Nicholas Miell
2005-01-04 23:04     ` Anton Altaparmakov
2005-01-05  0:48       ` Nicholas Miell
2005-01-05  1:12         ` Nicholas Miell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41D9EDF6.1060600@zytor.com \
    --to=hpa@zytor.com \
    --cc=aia21@cantab.net \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.org \
    --cc=tridge@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox