[dcc2] MultiFile Transfer Headers

[Craig Edwards]

the only thing of use out of all of this is the BINARY/TEXT flag.

This has use over all systems as we could do similar to in ftp, and have (auto detected) text mode or binary mode transfers, text mode transfers interpreting linefeeds on the target system so that we dont end up with text files sent with 'weird' linefeeds (e.g. seeing \r\n linefeeds on a \n\r system)...

Thanks,
Craig Edwards

>
>> 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.
>
>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.
>
>-- codemastr
>_______________________________________________
>dcc2 mailing list
>dcc2 at dcc2.org
>http://six.pairlist.net/mailman/listinfo/dcc2