[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] OS-dependent LDIF 'attr:< file://filename' handling
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:-)
--
Regards,
Hallvard
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext