Hallvard B Furuseth wrote:
Well, there's two possibilities here - on those oddball systems, either
a solution exists, or it doesn't. Any system that can't provide binary
byte-stream file semantics is going to have trouble with all kinds of
URLs in all kinds of software, not just LDAP.
Michael Ströder writes:
On 8:52:32 pm 2007-06-03 Hallvard B Furuseth <h.b.furuseth@xxxxxxxxxxx>
How do LDAP implementations handle "attr:< file:///foo/bar" on
If the file is opened in binary mode, the value may get zero-padded
at the end (to fill a complete block in the filesystem).
I don't understand the problem. The OS takes care of it.
If it can. There are or have been filesystems where file sizes are
not stored in number of bytes but number of blocks. That's why ^Z was
needed in text files on DOS or whatever - to get better granularity
than blocks it needed a character to work like an EOF mark.
(There are other kinds of filesystems or file types - e.g. files with
fixed-length records instead of streams of bytes. When used for text
files, they might use one record per line and space-pad it, hence
the "space may be removed at the end of lines in text files".)
Could you please give an example of an OS which returns zero-padded
data to an application when opening a file in binary mode?
Me? No. Well, DOS if I remember that example correctly. But I'm a
Unix person, which is why I asked about non-Unix.
But if it is opened in text mode,
I'd never do this.
That's a relief:-)
As for DOS - that EOF marker isn't actually needed, since the directory
structure records file sizes in bytes. Just a holdover from DOS 1.x or
somesuch (CP/M perhaps?).
re: record-oriented files - mainframes have a great variety of these. It
seems the file: URL syntax doesn't accommodate these details, so anyone
trying to use those files as anything other than a byte-stream is SOL. A
bit of a shame, but then again, they have other utilities available for
repacking a structured file into a byte-stream if necessary. Having
implemented structured file support in FTP for our mainframes a couple
decades ago, and seeing how few other systems cared, I'd say it's no
re: fixed-length records for text - that would be pretty unusual since
OS's with record-oriented files always provide both variable and fixed
options. Anybody who deliberately chose to use a fixed-length format for
text already knows there will be pad bytes, and probably expects them to
be propagated. Really it doesn't seem that any of this is worth worrying
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Ldapext mailing list