[dcc2] MultiFile Transfer Headers

[Dave Johnson]

codemstr at ptdprolog.net writes:
> 
> > File permissions are a bit tricky, since each platform can specify them in 
> > a different manner.  Any suggestions?
> 
> I think the best suggestion is to ditch this idea. The reason is, it is much 
> MUCH more complex than simply adding a UNIX style bitmask. For example, 
> Solaris2 supports ACLs. So should we transmit the ACL? That could be huge. 
> Windows NT also has an ACL type thing. And some systems have more than the 
> simple rwx system. Windows, for example, has the binary/text flag. Windows 
> also has the archive flag, the system file flag, and even the OS protected 
> file flag. Should they be sent? Some OSes allow you to treat an "append" 
> different than a "write." And even on many UNIX based OSes. You have the S 
> flag (setuid, setgid, sticky). Plus, as someone else mentioned, you have 
> security issues/potential user confusion. "I just downloaded this file, how 
> come it won't let me write to it???" (+r) "It's .sh, why won't my system let 
> me execute it???" (-x) etc. Personally, I think the user should have control 
> over what the permissions are for file on his/her own system, not the sender.

I would also say ditch the permissions part, it's just too messy and
will lead to problems.  If permissions or complicated trees are
important to a user, sending an archived file is better.

> Honestly, I even see problems with the "created" header. UNIX doesn't have a 
> created time stamp. People often think it does, but it doesn't. UNIX stores 
> the modification time, and the access time for a file. The timestamp people 
> usually think of as the creation (because it is referred to as ctime) is 
> really the timestamp for inode change, not for file creation. So again, this 
> isn't something that can be handled across OSes. And, then if you can't set 
> the creation time, setting the modification time will just lead to 
> confusion. "This file was modified before it was created?" Etc. "Why was this 
> file created in the future?" Again, in my mind, the user should have control 
> over that information, not the sender. But one thing, if you do decide to 
> keep the timestamps, at least make it clear that the value should be in UTC 
> time. Otherwise you'll get all sorts of interesting conflicts.

Created can go, but a modified timestamp would be good, howerver what
format should it be in? iso-8601? rfc-822? something else?


-- 
Dave