[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] OS-dependent LDIF 'attr:< file://filename' handling



Hallvard B Furuseth wrote:
Michael Ströder writes:
On 8:52:32 pm 2007-06-03 Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
wrote:
How do LDAP implementations handle "attr:< file:///foo/bar" on
non-Unix filesystems?

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:-)

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.

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 great loss.

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 about.
--
-- 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
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext