Re: When file truncation happens by Basic's Open statement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




I evaluated the behavior from Basic for all of the different modes based on a specific build on a specific Linux platform. I did not read the code, nor did I test different platforms. I documented all of this in OOME on my web site. Don't remember the direct link, but, it is on http://www.pitonyak.org under my macros page. 

I also loop at a few other methods for opening files using a service that might be useful to you. 

On Friday, December 21, 2018 14:15 EST, Kaganski Mike <mikekaganski@xxxxxxxxxxx> wrote:
 
Hi!

On 21.12.2018 20:37, Takeshi Abe wrote:
> In order to tell whether the behavior reported in tdf#119102 [1] is a bug
> or not, I would like to understand the specification of LibO Basic's Open
> statement [2].
>
> The following table summarizes what current (master) LibO does, which I read
> from SbiStream::Open() in basic/source/runtime/iosys.cxx.
>
> ACCESS\FOR | APPEND | BINARY | INPUT | OUTPUT | RANDOM |
> ----------------------+--------+--------+-------+--------+--------+
> default | - | - | - | X | - |
> READ ("read only") | - | - | - | - | - |
> WRITE ("write only") | - | -(*) | X | X | -(**) |
> READ WRITE ("both") | - | -(*) | X | X | -(**) |
>
> "X": the runtime deletes the file of given path first if already exists;
> "-": it does not.
> (*) requested in i#18638 <https://bz.apache.org/ooo/show_bug.cgi?id=18638>;
> see commit 23b49669ab70cac72d5f6d955e7d2af617e6934e.
> (**) requested in i#61277 <https://bz.apache.org/ooo/show_bug.cgi?id=61277>;
> see commit 42a63dd0e81f13a84a5f551e03ede685e2bf34c7.
>
> So here is a couple of questions popping up on a confused soul:
>
> (1) What does the default ACCESS mode mean?
> Is it just the same as READ, WRITE, or READ WRITE?
> Or does it depends on given FOR mode?
>
> (2) Does 'FOR INPUT + ACCESS WRITE' or 'FOR OUTPUT + ACCESS READ' make
> any sense?

Cannot answer the questions; just for completeness, something you could
already know:

the current handling of BINARY opened for write was defined in commit
23b49669ab70cac72d5f6d955e7d2af617e6934e [1] for #i18638 [2].

[1]
https://git.libreoffice.org/core/+/23b49669ab70cac72d5f6d955e7d2af617e6934e%5E%21/
[2] https://bz.apache.org/ooo/show_bug.cgi?id=18638

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice



 
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux