From james.f.hester at gmail.com  Tue Jul  4 16:01:46 2017
From: james.f.hester at gmail.com (Jim Hester)
Date: Tue, 4 Jul 2017 16:01:46 +0200
Subject: [Rd] write.csv
In-Reply-To: <f74dd537-cc00-50aa-0f33-c097aa08914a@gmail.com>
References: <FEF25E56AFC7064784FA97C576467E0AC7ACBE68@pdexchbalwst01.ad.insee.intra>
 <bc3fc4f2-a7ab-d061-3ef3-999479643a46@gmail.com>
 <FEF25E56AFC7064784FA97C576467E0AC7ACBEE5@pdexchbalwst01.ad.insee.intra>
 <f74dd537-cc00-50aa-0f33-c097aa08914a@gmail.com>
Message-ID: <CAD6tx94WZzdeQXHFN=dkT+K7ZU6V-McRWM9tjU74hzG=KpRUEw@mail.gmail.com>

On linux at least you can use `/dev/full` [1] to test writing to a full device.

    > echo 'foo' > /dev/full
    bash: echo: write error: No space left on device

Although that won't be a perfect test for this case where part of the
file is written successfully.

An alternative suggestion for testing this is to create and mount a
loop device [2] with a small file.

[1]: https://en.wikipedia.org/wiki//dev/full
[2]: https://stackoverflow.com/a/16044420/2055486

On Tue, Jul 4, 2017 at 3:38 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
> On 04/07/2017 8:40 AM, Lipatz Jean-Luc wrote:
>>
>> I would really like the bug fixed. At least this one, because I know
>> people in my institute using this function.
>> I understand your arguments about open source, but I also saw in this mail
>> list a proposal for a fix for this bug for which there were no answer from
>> the people who are able to include it in the distribution. It looks like if
>> there were interesting bugs and the other ones.
>
>
> Please post a link to that, and I'll look.  Bug reports should be posted to
> the bug list.  It's unfortunate that it is currently so difficult to do so,
> but if they are only posted here, they are often overlooked.
>
>> I don't understand the other arguments : the example was reproduced with a
>> simple USB key and you cannot state that a disk will eternally be empty
>> enough, specially when it has several users.
>
>
> I am not denying that it's a bug, I'm just saying that it is a difficult one
> to test automatically (so we probably won't add a regression test once it's
> fixed), and it's not one that has been reported often.  I didn't know there
> were any reports before yours.
>
> Duncan Murdoch
>
>
>> JLL
>>
>>
>> -----Message d'origine-----
>> De : Duncan Murdoch [mailto:murdoch.duncan at gmail.com]
>> Envoy? : mardi 4 juillet 2017 14:24
>> ? : Lipatz Jean-Luc; r-devel at r-project.org
>> Objet : Re: [Rd] write.csv
>>
>> On 04/07/2017 5:40 AM, Lipatz Jean-Luc wrote:
>>>
>>> Hi all,
>>>
>>> I am currently studying how to generalize the usage of R in my
>>> statistical institute and I encountered a problem that I cannot declare on
>>> bugzilla (cannot understand why).
>>
>>
>> Bugzilla was badly abused by spammers last year, so you need to have your
>> account created manually by one of the admins to post there.  Write to me
>> privately if you'd like me to create an account for you.  (If you want it
>> attached to a different email address, that's fine.)
>>
>> Sorry for trying this mailing list but I am really worried about the
>> problem itself and the possible implications in using R in a professionnal
>> data production context.
>>>
>>> The issue about 'write.csv' is that it just doesn't check if there is
>>> enough space on disk and doesn't report failure to write data.
>>>
>>> Example (R 3.4.0 windows 32 bits, but I reproduced the problem with older
>>> versions and under Mac OS/X)
>>>
>>>> fwrite(as.list(1:1000000),"G:/Test")
>>>
>>> Error in fwrite(as.list(1:1e+06), "G:/Test") :
>>>   No space left on device: 'G:/Test'
>>>>
>>>> write.csv(1:1000000,"G:/Test")
>>>>
>>>
>>> I have a big concern here, because it means that you could save some
>>> important data at one point of time and discover a long time after that you
>>> actually lost them.
>>
>>  > I suppose that the fix is relatively straightforward, but how can we
>> be sure that there is no another function with the same bad properties?
>>
>> R is open source.  You could work out the patch for this bug, and in the
>> process see the pattern of coding that leads to it.  Then you'll know if
>> other functions use the same buggy pattern.
>>
>>> Is the lesson that you should not use a R function, even from the core,
>>> without having personnally tested it against extreme conditions?
>>
>>
>> I think the answer to that is yes.  Most people never write such big
>> files that they fill their disk:  if they did, all sorts of things would
>> go wrong on their systems.  So this kind of extreme condition isn't
>> often tested.  It's not easy to test in a platform independent way:  R
>> would need to be able to create a volume with a small capacity.  That's
>> a very system-dependent thing to do.
>>
>>> And wouldn't it be the work of the developpers to do such elementary
>>> tests?
>>
>>
>> Again, R is open source.  You can and should contribute code (and
>> therefore become one of the developers) if you are working in unusual
>> conditions.
>>
>> R states quite clearly in the welcome message every time it starts: "R
>> is free software and comes with ABSOLUTELY NO WARRANTY."  This is
>> essentially the same lack of warranty that you get with commercial
>> software, though it's stated a lot more clearly.
>>
>> Duncan Murdoch
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] write.csv
Jim Hester