Revert of Return correct disk free/available size when FS is mounted with size = 0

Revert of Return correct disk free/available size when FS is mounted with size = 0 (patchset #4 id:60001 of https://codereview.chromium.org/2152283003/ )

Reason for revert:
Breaks host_forwarder on WebRTC bots: https://build.chromium.org/p/tryserver.webrtc/builders/android_arm64_rel/builds/9516/steps/compile/logs/stdio:

obj.host/chromium/src/base/base.sys_info_posix.o: In function `base::(anonymous namespace)::GetDiskSpaceInfo(base::FilePath const&, long*, long*)':
../../chromium/src/base/sys_info_posix.cc:(.text._ZN4base12_GLOBAL__N_116GetDiskSpaceInfoERKNS_8FilePathEPlS4_+0x4c): undefined reference to `base::GetFileSystemType(base::FilePath const&, base::FileSystemType*)'

I really don't know why it goes into the OS_LINUX branch since the bot is an Android bot though. host_forwarder is in the Chromium codebase. I would have understood it if it was WebRTC code since we have different macros (e.g. WEBRTC_LINUX) which would explain this breakage, but it appears to break host_forwarder.

Note that WebRTC will be on GYP a couple more weeks, so this could be a gyp-only problem. Presumably you'll be able to repro if you generate with gyp and try to build host_forwarder in a chromium checkout.

Original issue's description:
> Return correct disk free/available size when FS is mounted with size = 0
>
> When tmpfs is mounted with size = 0 (i.e. without any limit), then statvfs
> will return 0 for f_bfree, f_bavail, and f_blocks. Catch this case and return
> max_int64 instead.
>
> BUG=628710
>
> Committed: https://crrev.com/6c917630660164bb28d57f31b970b38591c0b8b1
> Cr-Commit-Position: refs/heads/master@{#406473}

TBR=thestig@chromium.org,reveman@chromium.org,sriramsr@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=628710
Committed: https://crrev.com/5b052f0889962f08c818ea5bd9a525bbfabe9a2f
Cr-Commit-Position: refs/heads/master@{#406825}

[phoglund_chromium, 2016-07-21 11:31:31]

The CQ bit was checked by phoglund@chromium.org

[phoglund_chromium, 2016-07-21 11:31:31]

Created Revert of Return correct disk free/available size when FS is mounted
with size = 0

[commit-bot: I haz the power, 2016-07-21 11:31:56]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-21 12:41:19]

Description was changed from

==========
Revert of Return correct disk free/available size when FS is mounted with size =
0 (patchset #4 id:60001 of https://codereview.chromium.org/2152283003/ )

Reason for revert:
Breaks host_forwarder on WebRTC bots:
https://build.chromium.org/p/tryserver.webrtc/builders/android_arm64_rel/buil...:

obj.host/chromium/src/base/base.sys_info_posix.o: In function `base::(anonymous
namespace)::GetDiskSpaceInfo(base::FilePath const&, long*, long*)':
../../chromium/src/base/sys_info_posix.cc:(.text._ZN4base12_GLOBAL__N_116GetDiskSpaceInfoERKNS_8FilePathEPlS4_+0x4c):
undefined reference to `base::GetFileSystemType(base::FilePath const&,
base::FileSystemType*)'

I really don't know why it goes into the OS_LINUX branch since the bot is an
Android bot though. host_forwarder is in the Chromium codebase. I would have
understood it if it was WebRTC code since we have different macros (e.g.
WEBRTC_LINUX) which would explain this breakage, but it appears to break
host_forwarder.

Note that WebRTC will be on GYP a couple more weeks, so this could be a gyp-only
problem. Presumably you'll be able to repro if you generate with gyp and try to
build host_forwarder in a chromium checkout.

Original issue's description:
> Return correct disk free/available size when FS is mounted with size = 0
> 
> When tmpfs is mounted with size = 0 (i.e. without any limit), then statvfs
> will return 0 for f_bfree, f_bavail, and f_blocks. Catch this case and return
> max_int64 instead.
> 
> BUG=628710
> 
> Committed: https://crrev.com/6c917630660164bb28d57f31b970b38591c0b8b1
> Cr-Commit-Position: refs/heads/master@{#406473}

TBR=thestig@chromium.org,reveman@chromium.org,sriramsr@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=628710
==========

to

==========
Revert of Return correct disk free/available size when FS is mounted with size =
0 (patchset #4 id:60001 of https://codereview.chromium.org/2152283003/ )

Reason for revert:
Breaks host_forwarder on WebRTC bots:
https://build.chromium.org/p/tryserver.webrtc/builders/android_arm64_rel/buil...:

obj.host/chromium/src/base/base.sys_info_posix.o: In function `base::(anonymous
namespace)::GetDiskSpaceInfo(base::FilePath const&, long*, long*)':
../../chromium/src/base/sys_info_posix.cc:(.text._ZN4base12_GLOBAL__N_116GetDiskSpaceInfoERKNS_8FilePathEPlS4_+0x4c):
undefined reference to `base::GetFileSystemType(base::FilePath const&,
base::FileSystemType*)'

I really don't know why it goes into the OS_LINUX branch since the bot is an
Android bot though. host_forwarder is in the Chromium codebase. I would have
understood it if it was WebRTC code since we have different macros (e.g.
WEBRTC_LINUX) which would explain this breakage, but it appears to break
host_forwarder.

Note that WebRTC will be on GYP a couple more weeks, so this could be a gyp-only
problem. Presumably you'll be able to repro if you generate with gyp and try to
build host_forwarder in a chromium checkout.

Original issue's description:
> Return correct disk free/available size when FS is mounted with size = 0
> 
> When tmpfs is mounted with size = 0 (i.e. without any limit), then statvfs
> will return 0 for f_bfree, f_bavail, and f_blocks. Catch this case and return
> max_int64 instead.
> 
> BUG=628710
> 
> Committed: https://crrev.com/6c917630660164bb28d57f31b970b38591c0b8b1
> Cr-Commit-Position: refs/heads/master@{#406473}

TBR=thestig@chromium.org,reveman@chromium.org,sriramsr@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=628710
==========

[commit-bot: I haz the power, 2016-07-21 12:41:20]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-21 12:43:28]

Description was changed from

==========
Revert of Return correct disk free/available size when FS is mounted with size =
0 (patchset #4 id:60001 of https://codereview.chromium.org/2152283003/ )

Reason for revert:
Breaks host_forwarder on WebRTC bots:
https://build.chromium.org/p/tryserver.webrtc/builders/android_arm64_rel/buil...:

obj.host/chromium/src/base/base.sys_info_posix.o: In function `base::(anonymous
namespace)::GetDiskSpaceInfo(base::FilePath const&, long*, long*)':
../../chromium/src/base/sys_info_posix.cc:(.text._ZN4base12_GLOBAL__N_116GetDiskSpaceInfoERKNS_8FilePathEPlS4_+0x4c):
undefined reference to `base::GetFileSystemType(base::FilePath const&,
base::FileSystemType*)'

I really don't know why it goes into the OS_LINUX branch since the bot is an
Android bot though. host_forwarder is in the Chromium codebase. I would have
understood it if it was WebRTC code since we have different macros (e.g.
WEBRTC_LINUX) which would explain this breakage, but it appears to break
host_forwarder.

Note that WebRTC will be on GYP a couple more weeks, so this could be a gyp-only
problem. Presumably you'll be able to repro if you generate with gyp and try to
build host_forwarder in a chromium checkout.

Original issue's description:
> Return correct disk free/available size when FS is mounted with size = 0
> 
> When tmpfs is mounted with size = 0 (i.e. without any limit), then statvfs
> will return 0 for f_bfree, f_bavail, and f_blocks. Catch this case and return
> max_int64 instead.
> 
> BUG=628710
> 
> Committed: https://crrev.com/6c917630660164bb28d57f31b970b38591c0b8b1
> Cr-Commit-Position: refs/heads/master@{#406473}

TBR=thestig@chromium.org,reveman@chromium.org,sriramsr@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=628710
==========

to

==========
Revert of Return correct disk free/available size when FS is mounted with size =
0 (patchset #4 id:60001 of https://codereview.chromium.org/2152283003/ )

Reason for revert:
Breaks host_forwarder on WebRTC bots:
https://build.chromium.org/p/tryserver.webrtc/builders/android_arm64_rel/buil...:

obj.host/chromium/src/base/base.sys_info_posix.o: In function `base::(anonymous
namespace)::GetDiskSpaceInfo(base::FilePath const&, long*, long*)':
../../chromium/src/base/sys_info_posix.cc:(.text._ZN4base12_GLOBAL__N_116GetDiskSpaceInfoERKNS_8FilePathEPlS4_+0x4c):
undefined reference to `base::GetFileSystemType(base::FilePath const&,
base::FileSystemType*)'

I really don't know why it goes into the OS_LINUX branch since the bot is an
Android bot though. host_forwarder is in the Chromium codebase. I would have
understood it if it was WebRTC code since we have different macros (e.g.
WEBRTC_LINUX) which would explain this breakage, but it appears to break
host_forwarder.

Note that WebRTC will be on GYP a couple more weeks, so this could be a gyp-only
problem. Presumably you'll be able to repro if you generate with gyp and try to
build host_forwarder in a chromium checkout.

Original issue's description:
> Return correct disk free/available size when FS is mounted with size = 0
>
> When tmpfs is mounted with size = 0 (i.e. without any limit), then statvfs
> will return 0 for f_bfree, f_bavail, and f_blocks. Catch this case and return
> max_int64 instead.
>
> BUG=628710
>
> Committed: https://crrev.com/6c917630660164bb28d57f31b970b38591c0b8b1
> Cr-Commit-Position: refs/heads/master@{#406473}

TBR=thestig@chromium.org,reveman@chromium.org,sriramsr@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=628710

Committed: https://crrev.com/5b052f0889962f08c818ea5bd9a525bbfabe9a2f
Cr-Commit-Position: refs/heads/master@{#406825}
==========

[commit-bot: I haz the power, 2016-07-21 12:43:29]

Patchset 1 (id:??) landed as
https://crrev.com/5b052f0889962f08c818ea5bd9a525bbfabe9a2f
Cr-Commit-Position: refs/heads/master@{#406825}

[Lei Zhang, 2016-07-21 19:16:51]

phoglud: It seems unfortunate that we have to revert for a bot that has no
coverage on the main Chromium waterfall, though I think this is hitting an
existing bug in base/.

My guess is either:

a) both GetFileSystemType() and its caller in sys_info_posix.cc needs be behind
#if defined(OS_LINUX) || !defined(OS_ANDROID)

or

b) The GetFileSystemType() impl needs to be moved into file_util_posix.cc and
remain gated on just OS_LINUX.

[phoglund_chromium, 2016-07-22 09:16:37]

Yes, it is unfortunate, and I'm sure it's frustrating to get a patch reverted
for that reason. We're in a weird spot in WebRTC since we live downstream and
use all of Chromium's build scripts. In practice we often manage to adapt to
what's coming from upstream, but in this case I had no idea what I could do to
adapt WebRTC. Maybe it was a legit bug, like you described?

One big problem right now is that we're still on gyp and it's rotting fast now
that Chromium is on GN, so it's going to be a few weeks where we are going to be
annoying to upstream and revert things. We're going to try to keep it to a
minimum.

Anyway, I think trying to build host_forwarder using gyp hopefully reproduces
this problem, and just requires either some changes to a gyp file or fixing the
#ifdef.

[Lei Zhang, 2016-07-22 10:04:30]

On 2016/07/22 09:16:37, phoglund_chrome wrote:
> Yes, it is unfortunate, and I'm sure it's frustrating to get a patch reverted
> for that reason. We're in a weird spot in WebRTC since we live downstream and
> use all of Chromium's build scripts. In practice we often manage to adapt to
> what's coming from upstream, but in this case I had no idea what I could do to
> adapt WebRTC. Maybe it was a legit bug, like you described?
> 
> One big problem right now is that we're still on gyp and it's rotting fast now
> that Chromium is on GN, so it's going to be a few weeks where we are going to
be
> annoying to upstream and revert things. We're going to try to keep it to a
> minimum.
> 
> Anyway, I think trying to build host_forwarder using gyp hopefully reproduces
> this problem, and just requires either some changes to a gyp file or fixing
the
> #ifdef.

With my local Chromium Android checkout, host_forwarder builds fine with GN +
the reverted CL. GYP does not run to completion, so I cannot test a GYP build at
all.

I assume Sriram will need to start with "fetch webrtc" or "fetch webrtc_android"
and build host_forwarder in that checkout.

[phoglund_chromium, 2016-07-22 11:31:34]

Really, so gyp is dying that fast? Oh dear. Yes, do fetch webrtc_android and try
building host_forwarder. After fetching WebRTC, notice the chromium folder in
the checkout's src directory. This is a complete Chromium checkout that WebRTC
uses. Patch your CL in there and try building host_forwarder out in WebRTC
(note: NOT in chromium). WebRTC uses chromium build scripts by symlinking into
its internal chromium checkout (for instance, build -> chromium/src/build). For
certain Android tests, it actually uses some chrome base code directly (this is
very unfortunate and we should wean ourselves off using that code).

[Lei Zhang, 2016-07-22 17:23:13]

On 2016/07/22 11:31:34, phoglund_chrome wrote:
> Really, so gyp is dying that fast? Oh dear.

The Android build was the first to completely switch over to GN, at least 2
months ago.

[phoglund_chromium, 2016-07-25 07:25:47]

On 2016/07/22 17:23:13, Lei Zhang wrote:
> On 2016/07/22 11:31:34, phoglund_chrome wrote:
> > Really, so gyp is dying that fast? Oh dear.
> 
> The Android build was the first to completely switch over to GN, at least 2
> months ago.

Ok, I see.