summaryrefslogtreecommitdiffstats
path: root/base/files
Commit message (Collapse)AuthorAgeFilesLines
* Fix file path notification filtering on Windows.vandebo@chromium.org2014-05-191-9/+18
| | | | | | | | | | | | first_notification_ was getting reset on each notification in UpdateWatch, causing the filtering to be less effective than it should have been. BUG=NONE Review URL: https://codereview.chromium.org/273843004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@271414 0039d316-1c4b-4281-b951-d872f2087c98
* Replace FileUtilProxy with FileProxy in renderer_host/pepperrvargas@chromium.org2014-05-153-11/+31
| | | | | | | | BUG=322664 Review URL: https://codereview.chromium.org/252583007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@270781 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: Implement recursive file watching.thestig@chromium.org2014-05-132-31/+181
| | | | | | | | | | Also fix catching file attribute changes. BUG=78043 Review URL: https://codereview.chromium.org/275543007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@270165 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce a new framework for back-and-forth tracked preference migrationgab@chromium.org2014-05-123-12/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between Protected Preferences and unprotected Preferences. Migration from unprotected Preferences to Protected Preferences was previously done after both stores had been initialized. This was inherently incorrect as some operations (PrefHashFilter::FilterOnLoad) would occur before the values had been moved to the proper store. It also introduced a weird method in PrefHashFilter::MigrateValues which required an independent PrefHashFilter (backed by a copy of the real PrefHashStore). This after-the-fact migration caused Settings.TrackedPreferenceCleared spikes when changing a value from being enforced to not being enforced (as we'd have a MAC, but no value yet in this store when running FilterOnLoad()) and more importantly it also caused issue 365769 -- both of these issues highlight the incorrectness of the current approach. The migration back from Protected Preferences to unprotected Preferences when enforcement was disabled was using yet another mechanism which would only kick in when a given pref was written to (ref. old non-const SegregatedPrefStore::StoreForKey()). The new framework intercepts PrefFilter::FilterOnLoad() events for both stores and does the back-and-forth migration in place before it even hands them back to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the JsonPrefStores (so that they are agnostic to the migration; from their point of view their values were always in their store as they received it). Furthermore, this new framework will easily allow us to later move MACs out of Local State into their respective stores (which is a task on our radar which we currently have no easy way to accomplish). The new framework also handles read errors better. For example, it was previously possible for the unprotected->protected migration to result in data loss if the protected store was somehow read-only from a read error while the unprotected store wasn't -- resulting in an in-memory migration only flushed to disk in the store from which the value was deleted... The new framework handles those cases, preferring temporary data duplication over potential data loss (duplicated data is cleaned up once confirmation is obtained that the new authority for this data has been successfully written to disk -- it will even try again in following Chrome runs if it doesn't succeed in this one). Note: This CL helped LSAN discover an existing leak in post_task_and_reply_impl.cc, see issue 371974 for details. BUG=365769, 371974 TEST= A) Make sure all kTrackedPrefs consistently report Settings.TrackedPreferenceUnchanged across changes from various enforcement levels (using --force-fieldtrials). B) Make sure the prefs are properly migrated to their new store (and subsequently cleaned up from their old store) when changing the enforcement_level across multiple runs. C) Make sure prefs are properly migrated in a quick startup/shutdown with a new enforcement_level and that their old value is properly cleaned up in a subsequent startup at the same enforcement_level (or re-migrated at another enforcement_level). R=bauerb@chromium.org, robertshield@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org Initially Committed in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269346 Reverted in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269367 Committed again: https://src.chromium.org/viewvc/chrome?view=rev&revision=269415 Reverted again: https://src.chromium.org/viewvc/chrome?view=rev&revision=269438 Review URL: https://codereview.chromium.org/257003007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269735 0039d316-1c4b-4281-b951-d872f2087c98
* Adding myself as owner of base/files and base/winrvargas@chromium.org2014-05-111-0/+2
| | | | | | | | | R=brettw@chromium.org BUG= Review URL: https://codereview.chromium.org/279623002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269651 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 269415 "Introduce a new framework for back-and-forth trac..."ananta@chromium.org2014-05-093-115/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverting because this appears to have caused Linux TSAN redness. > Introduce a new framework for back-and-forth tracked preference migration > between Protected Preferences and unprotected Preferences. > > Migration from unprotected Preferences to Protected Preferences was previously > done after both stores had been initialized. This was inherently incorrect as > some operations (PrefHashFilter::FilterOnLoad) would occur before the values > had been moved to the proper store. It also introduced a weird method in > PrefHashFilter::MigrateValues which required an independent PrefHashFilter > (backed by a copy of the real PrefHashStore). This after-the-fact migration > caused Settings.TrackedPreferenceCleared spikes when changing a value from > being enforced to not being enforced (as we'd have a MAC, but no value yet in > this store when running FilterOnLoad()) and more importantly it also caused > issue 365769 -- both of these issues highlight the incorrectness of the > current approach. > > The migration back from Protected Preferences to unprotected Preferences when > enforcement was disabled was using yet another mechanism which would only kick > in when a given pref was written to (ref. old non-const > SegregatedPrefStore::StoreForKey()). > > The new framework intercepts PrefFilter::FilterOnLoad() events for both stores > and does the back-and-forth migration in place before it even hands them back > to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the > JsonPrefStores (so that they are agnostic to the migration; from their point > of view their values were always in their store as they received it). > Furthermore, this new framework will easily allow us to later move MACs out of > Local State into their respective stores (which is a task on our radar which > we currently have no easy way to accomplish). > > The new framework also handles read errors better. For example, it was > previously possible for the unprotected->protected migration to result in data > loss if the protected store was somehow read-only from a read error while the > unprotected store wasn't -- resulting in an in-memory migration only flushed > to disk in the store from which the value was deleted... The new framework > handles those cases, preferring temporary data duplication over potential data > loss (duplicated data is cleaned up once confirmation is obtained that the new > authority for this data has been successfully written to disk -- it will even > try again in following Chrome runs if it doesn't succeed in this one). > > Note: This CL helped LSAN discover an existing leak in post_task_and_reply_impl.cc, see issue 371974 for details. > > BUG=365769, 371974 > TEST= > A) Make sure all kTrackedPrefs consistently report > Settings.TrackedPreferenceUnchanged across changes from various enforcement > levels (using --force-fieldtrials). > B) Make sure the prefs are properly migrated to their new store (and > subsequently cleaned up from their old store) when changing the > enforcement_level across multiple runs. > C) Make sure prefs are properly migrated in a quick startup/shutdown with a > new enforcement_level and that their old value is properly cleaned up in a > subsequent startup at the same enforcement_level (or re-migrated at another > enforcement_level). > > R=bauerb@chromium.org, robertshield@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org > > Initially Committed in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269346 > Reverted in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269367 > > Review URL: https://codereview.chromium.org/257003007 TBR=gab@chromium.org Review URL: https://codereview.chromium.org/273243002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269438 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce a new framework for back-and-forth tracked preference migrationgab@chromium.org2014-05-093-10/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between Protected Preferences and unprotected Preferences. Migration from unprotected Preferences to Protected Preferences was previously done after both stores had been initialized. This was inherently incorrect as some operations (PrefHashFilter::FilterOnLoad) would occur before the values had been moved to the proper store. It also introduced a weird method in PrefHashFilter::MigrateValues which required an independent PrefHashFilter (backed by a copy of the real PrefHashStore). This after-the-fact migration caused Settings.TrackedPreferenceCleared spikes when changing a value from being enforced to not being enforced (as we'd have a MAC, but no value yet in this store when running FilterOnLoad()) and more importantly it also caused issue 365769 -- both of these issues highlight the incorrectness of the current approach. The migration back from Protected Preferences to unprotected Preferences when enforcement was disabled was using yet another mechanism which would only kick in when a given pref was written to (ref. old non-const SegregatedPrefStore::StoreForKey()). The new framework intercepts PrefFilter::FilterOnLoad() events for both stores and does the back-and-forth migration in place before it even hands them back to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the JsonPrefStores (so that they are agnostic to the migration; from their point of view their values were always in their store as they received it). Furthermore, this new framework will easily allow us to later move MACs out of Local State into their respective stores (which is a task on our radar which we currently have no easy way to accomplish). The new framework also handles read errors better. For example, it was previously possible for the unprotected->protected migration to result in data loss if the protected store was somehow read-only from a read error while the unprotected store wasn't -- resulting in an in-memory migration only flushed to disk in the store from which the value was deleted... The new framework handles those cases, preferring temporary data duplication over potential data loss (duplicated data is cleaned up once confirmation is obtained that the new authority for this data has been successfully written to disk -- it will even try again in following Chrome runs if it doesn't succeed in this one). Note: This CL helped LSAN discover an existing leak in post_task_and_reply_impl.cc, see issue 371974 for details. BUG=365769, 371974 TEST= A) Make sure all kTrackedPrefs consistently report Settings.TrackedPreferenceUnchanged across changes from various enforcement levels (using --force-fieldtrials). B) Make sure the prefs are properly migrated to their new store (and subsequently cleaned up from their old store) when changing the enforcement_level across multiple runs. C) Make sure prefs are properly migrated in a quick startup/shutdown with a new enforcement_level and that their old value is properly cleaned up in a subsequent startup at the same enforcement_level (or re-migrated at another enforcement_level). R=bauerb@chromium.org, robertshield@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org Initially Committed in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269346 Reverted in: https://src.chromium.org/viewvc/chrome?view=rev&revision=269367 Review URL: https://codereview.chromium.org/257003007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269415 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 269346 "Introduce a new framework for back-and-forth trac..."rlp@chromium.org2014-05-093-115/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fails JsonPrefStoreTest.RemoveClearsEmptyParent on Linux ASan. http://build.chromium.org/p/chromium.memory/builders/Linux%20ASan%20LSan%20Tests%20%281%29/builds/2074/steps/base_unittests/logs/RemoveClearsEmptyParent > Introduce a new framework for back-and-forth tracked preference migration > between Protected Preferences and unprotected Preferences. > > Migration from unprotected Preferences to Protected Preferences was previously > done after both stores had been initialized. This was inherently incorrect as > some operations (PrefHashFilter::FilterOnLoad) would occur before the values > had been moved to the proper store. It also introduced a weird method in > PrefHashFilter::MigrateValues which required an independent PrefHashFilter > (backed by a copy of the real PrefHashStore). This after-the-fact migration > caused Settings.TrackedPreferenceCleared spikes when changing a value from > being enforced to not being enforced (as we'd have a MAC, but no value yet in > this store when running FilterOnLoad()) and more importantly it also caused > issue 365769 -- both of these issues highlight the incorrectness of the > current approach. > > The migration back from Protected Preferences to unprotected Preferences when > enforcement was disabled was using yet another mechanism which would only kick > in when a given pref was written to (ref. old non-const > SegregatedPrefStore::StoreForKey()). > > The new framework intercepts PrefFilter::FilterOnLoad() events for both stores > and does the back-and-forth migration in place before it even hands them back > to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the > JsonPrefStores (so that they are agnostic to the migration; from their point > of view their values were always in their store as they received it). > Furthermore, this new framework will easily allow us to later move MACs out of > Local State into their respective stores (which is a task on our radar which > we currently have no easy way to accomplish). > > The new framework also handles read errors better. For example, it was > previously possible for the unprotected->protected migration to result in data > loss if the protected store was somehow read-only from a read error while the > unprotected store wasn't -- resulting in an in-memory migration only flushed > to disk in the store from which the value was deleted... The new framework > handles those cases, preferring temporary data duplication over potential data > loss (duplicated data is cleaned up once confirmation is obtained that the new > authority for this data has been successfully written to disk -- it will even > try again in following Chrome runs if it doesn't succeed in this one). > > BUG=365769 > TEST= > A) Make sure all kTrackedPrefs consistently report > Settings.TrackedPreferenceUnchanged across changes from various enforcement > levels (using --force-fieldtrials). > B) Make sure the prefs are properly migrated to their new store (and > subsequently cleaned up from their old store) when changing the > enforcement_level across multiple runs. > C) Make sure prefs are properly migrated in a quick startup/shutdown with a > new enforcement_level and that their old value is properly cleaned up in a > subsequent startup at the same enforcement_level (or re-migrated at another > enforcement_level). > > R=bauerb@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org > > Review URL: https://codereview.chromium.org/257003007 TBR=gab@chromium.org Review URL: https://codereview.chromium.org/279943002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269367 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce a new framework for back-and-forth tracked preference migrationgab@chromium.org2014-05-093-10/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | between Protected Preferences and unprotected Preferences. Migration from unprotected Preferences to Protected Preferences was previously done after both stores had been initialized. This was inherently incorrect as some operations (PrefHashFilter::FilterOnLoad) would occur before the values had been moved to the proper store. It also introduced a weird method in PrefHashFilter::MigrateValues which required an independent PrefHashFilter (backed by a copy of the real PrefHashStore). This after-the-fact migration caused Settings.TrackedPreferenceCleared spikes when changing a value from being enforced to not being enforced (as we'd have a MAC, but no value yet in this store when running FilterOnLoad()) and more importantly it also caused issue 365769 -- both of these issues highlight the incorrectness of the current approach. The migration back from Protected Preferences to unprotected Preferences when enforcement was disabled was using yet another mechanism which would only kick in when a given pref was written to (ref. old non-const SegregatedPrefStore::StoreForKey()). The new framework intercepts PrefFilter::FilterOnLoad() events for both stores and does the back-and-forth migration in place before it even hands them back to the PrefFilter::FinalizeFilterOnLoad() which then hands it back to the JsonPrefStores (so that they are agnostic to the migration; from their point of view their values were always in their store as they received it). Furthermore, this new framework will easily allow us to later move MACs out of Local State into their respective stores (which is a task on our radar which we currently have no easy way to accomplish). The new framework also handles read errors better. For example, it was previously possible for the unprotected->protected migration to result in data loss if the protected store was somehow read-only from a read error while the unprotected store wasn't -- resulting in an in-memory migration only flushed to disk in the store from which the value was deleted... The new framework handles those cases, preferring temporary data duplication over potential data loss (duplicated data is cleaned up once confirmation is obtained that the new authority for this data has been successfully written to disk -- it will even try again in following Chrome runs if it doesn't succeed in this one). BUG=365769 TEST= A) Make sure all kTrackedPrefs consistently report Settings.TrackedPreferenceUnchanged across changes from various enforcement levels (using --force-fieldtrials). B) Make sure the prefs are properly migrated to their new store (and subsequently cleaned up from their old store) when changing the enforcement_level across multiple runs. C) Make sure prefs are properly migrated in a quick startup/shutdown with a new enforcement_level and that their old value is properly cleaned up in a subsequent startup at the same enforcement_level (or re-migrated at another enforcement_level). R=bauerb@chromium.org, stuartmorgan@chromium.org, thakis@chromium.org Review URL: https://codereview.chromium.org/257003007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@269346 0039d316-1c4b-4281-b951-d872f2087c98
* Move IsStringUTF8/ASCII to base namespacebrettw@chromium.org2014-05-071-3/+3
| | | | | | | | TBR=sky@chromium.org Review URL: https://codereview.chromium.org/270183002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@268754 0039d316-1c4b-4281-b951-d872f2087c98
* Base: Make FileProxy automaticaly close the file on a worker thread.rvargas@chromium.org2014-05-064-11/+37
| | | | | | | | | | | | | | | This CL removes the restriction that callers should call Close before deleting the object if they want to make sure the file is not closed on the current thread. BUG=322664 TEST=base_unittests Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=263675 Review URL: https://codereview.chromium.org/231703002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@268348 0039d316-1c4b-4281-b951-d872f2087c98
* Render comment for FilePath::ReferencesParent() more precisely.tnagel@chromium.org2014-05-011-2/+2
| | | | | | | | BUG=none Review URL: https://codereview.chromium.org/263553011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267540 0039d316-1c4b-4281-b951-d872f2087c98
* Clean up the Linux FileWatcher implementation.thestig@chromium.org2014-04-261-123/+143
| | | | | | Review URL: https://codereview.chromium.org/250833003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@266387 0039d316-1c4b-4281-b951-d872f2087c98
* Revert of Base: Make FileProxy automaticaly close the file on a worker ↵leviw@chromium.org2014-04-154-37/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | thread. (https://codereview.chromium.org/231703002/) Reason for revert: Triggering AssertIOAllowed on a handful of Blink LayoutTests. Original issue's description: > Base: Make FileProxy automaticaly close the file on a worker thread. > > This CL removes the restriction that callers should call Close before > deleting the object if they want to make sure the file is not closed > on the current thread. > > BUG=322664 > TEST=base_unittests > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=263675 TBR=willchan@chromium.org,rvargas@chromium.org NOTREECHECKS=true NOTRY=true BUG=322664 Review URL: https://codereview.chromium.org/238383003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@263758 0039d316-1c4b-4281-b951-d872f2087c98
* Base: Make FileProxy automaticaly close the file on a worker thread.rvargas@chromium.org2014-04-144-11/+37
| | | | | | | | | | | | | This CL removes the restriction that callers should call Close before deleting the object if they want to make sure the file is not closed on the current thread. BUG=322664 TEST=base_unittests Review URL: https://codereview.chromium.org/231703002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@263675 0039d316-1c4b-4281-b951-d872f2087c98
* Remove CreatePlatformFile from file_util_proxyrvargas@chromium.org2014-04-092-16/+18
| | | | | | | | | | | | | Most of file_util_proxy is going to be deleted soon (users have to migrate to FileProxy) so this CL is quite superficial. It is intended to remove the last uses of CreatePlatformFile so that the method can be removed and no new code can ignore base::File. BUG=322664 Review URL: https://codereview.chromium.org/227433006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@262781 0039d316-1c4b-4281-b951-d872f2087c98
* Base: Make file_util and file use the same code to translate from stat to ↵rvargas@chromium.org2014-04-053-53/+66
| | | | | | | | | | File::Info BUG=353318 Review URL: https://codereview.chromium.org/203873002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@261956 0039d316-1c4b-4281-b951-d872f2087c98
* GN: Move towards only using / on Windowsscottmg@chromium.org2014-04-032-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | Remove most of the \ handling code, and start some normalization to / as necessary. Paths that come from actions, etc. aren't validated yet. This makes the Windows build get farther, but now it fails with things similar to: ninja: Entering directory `out_gn2' ninja: error: WriteFile(obj/third_party/re2/re2/re2.unicode_groups.obj.rsp): Unable to create file. No such file or directory Looks like we're not creating the subtree for ninja to write rsp files to? Not sure. This removes the last argument from rebase_path, so might have some migration issues in landing the binary. R=brettw@chromium.org BUG=354626 Review URL: https://codereview.chromium.org/213353004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@261311 0039d316-1c4b-4281-b951-d872f2087c98
* Implement Read/WriteAtCurrentPos correctlyhashimoto@chromium.org2014-03-311-2/+3
| | | | | | | | BUG=356979 Review URL: https://codereview.chromium.org/213473007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@260673 0039d316-1c4b-4281-b951-d872f2087c98
* Remove PlatforFile from fileapi/native_file_utilrvargas@chromium.org2014-03-263-1/+22
| | | | | | | | BUG=322664 Review URL: https://codereview.chromium.org/206783004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@259540 0039d316-1c4b-4281-b951-d872f2087c98
* net: Update FileStream to use base::File instead of PlatformFile.rvargas@chromium.org2014-03-213-18/+39
| | | | | | | | | | | | | As collateral damage, OpenContentUriForRead is now returning File instead of a plain file descriptor. BUG=322664 TEST=net_unittests R=willchan@chromium.org Review URL: https://codereview.chromium.org/189393002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@258472 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 257577 "Revert 257562 "Base: Make base::File use ScopedFD..."zmo@chromium.org2014-03-184-29/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reland this: turns out not responsible. > Revert 257562 "Base: Make base::File use ScopedFD on POSIX." > > Might caused a bunch of layout test failures, at least on Linux > > fast/dom/Window/property-access-on-cached-properties-after-frame-navigated.html, > fast/dom/Window/property-access-on-cached-properties-after-frame-removed.html, > fast/dom/Window/property-access-on-cached-window-after-frame-navigated.html, > fast/dom/Window/property-access-on-cached-window-after-frame-removed.html > > > Base: Make base::File use ScopedFD on POSIX. > > > > Now that ScopedFD lives outside of file_util, File can use it to remove manual > > lifetime management. > > > > This also standarizes the behavior on Close failures for all platforms. > > > > BUG=none > > > > Review URL: https://codereview.chromium.org/201083002 > > TBR=rvargas@chromium.org > > Review URL: https://codereview.chromium.org/202583005 TBR=zmo@chromium.org Review URL: https://codereview.chromium.org/202493007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257581 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 257562 "Base: Make base::File use ScopedFD on POSIX."zmo@chromium.org2014-03-184-39/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | Might caused a bunch of layout test failures, at least on Linux fast/dom/Window/property-access-on-cached-properties-after-frame-navigated.html, fast/dom/Window/property-access-on-cached-properties-after-frame-removed.html, fast/dom/Window/property-access-on-cached-window-after-frame-navigated.html, fast/dom/Window/property-access-on-cached-window-after-frame-removed.html > Base: Make base::File use ScopedFD on POSIX. > > Now that ScopedFD lives outside of file_util, File can use it to remove manual > lifetime management. > > This also standarizes the behavior on Close failures for all platforms. > > BUG=none > > Review URL: https://codereview.chromium.org/201083002 TBR=rvargas@chromium.org Review URL: https://codereview.chromium.org/202583005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257577 0039d316-1c4b-4281-b951-d872f2087c98
* Base: Make base::File use ScopedFD on POSIX.rvargas@chromium.org2014-03-184-29/+39
| | | | | | | | | | | | | Now that ScopedFD lives outside of file_util, File can use it to remove manual lifetime management. This also standarizes the behavior on Close failures for all platforms. BUG=none Review URL: https://codereview.chromium.org/201083002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257562 0039d316-1c4b-4281-b951-d872f2087c98
* Move ScopedFILE to base namespace and scoped_file.hbrettw@chromium.org2014-03-171-0/+14
| | | | | | | | R=viettrungluu@chromium.org Review URL: https://codereview.chromium.org/196073002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257518 0039d316-1c4b-4281-b951-d872f2087c98
* Implement ScopedFD in terms of ScopedGeneric.brettw@chromium.org2014-03-172-0/+82
| | | | | | | | | | | | | | | Move to a new file base/files/scoped_file.h. I will also add ScopedFILE to here (currently in file_util.h) later. I think there is a crash in the old code in content/browser/zygote_host/zygote_host_impl_linux.cc that this patch should fix. The old ScopedFD took the address of something in a vector that is being modified. I removed SafeScopedFD from content/common/sandbox_linux/sandbox_linux.cc since base's ScopedFD not CHECKs on close failure (this is a more recent addition). Reland of https://codereview.chromium.org/191673003/ R=agl, viettrungluu Review URL: https://codereview.chromium.org/202113004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257473 0039d316-1c4b-4281-b951-d872f2087c98
* Revert of Implement ScopedFD in terms of ScopedGeneric. ↵jochen@chromium.org2014-03-152-82/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/191673003/) Reason for revert: Doesn't correctly link /mnt/data/b/build/slave/Chromium_Linux_Codesearch/build/src/third_party/gold/gold64: warning: hidden symbol 'base::internal::ScopedFDCloseTraits::Free(int)' in obj/base/files/nacl_helper.scoped_file.o is referenced by DSO lib/libipc.so Original issue's description: > Implement ScopedFD in terms of ScopedGeneric. > > Move to a new file base/files/scoped_file.h. I will also add ScopedFILE to here (currently in file_util.h) later. > > I think there is a crash in the old code in content/browser/zygote_host/zygote_host_impl_linux.cc that this patch should fix. The old ScopedFD took the address of something in a vector that is being modified. > > I removed SafeScopedFD from content/common/sandbox_linux/sandbox_linux.cc since base's ScopedFD not CHECKs on close failure (this is a more recent addition). > > BUG= > R=agl@chromium.org, viettrungluu@chromium.org > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257001 > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257179 TBR=viettrungluu@chromium.org,agl@chromium.org,brettw@chromium.org NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/201203002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257323 0039d316-1c4b-4281-b951-d872f2087c98
* Base: Introduce a new version of FileUtilProxy that works with File.rvargas@chromium.org2014-03-153-0/+833
| | | | | | | | | BUG=322664 TEST=net_unittests Review URL: https://codereview.chromium.org/180243015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257290 0039d316-1c4b-4281-b951-d872f2087c98
* Move UTF16ToASCII, remove WideToASCII.brettw@chromium.org2014-03-141-2/+2
| | | | | | | | | | | | | | | | This removes WideToASCII and changes all callers to use UTF16ToASCII instead. Moves UTF16ToASCII from base/strings/string_util.h to base/strings/utf_string_conversions.h and into the base namespace. Convert a few related string_util functions to take a StringPiece16 instead of a string16. Remove IsStringASCII(std::wstring) which was unused. Updates callers' includes and namespace usage accordingly. TBR=sky Review URL: https://codereview.chromium.org/176843022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257200 0039d316-1c4b-4281-b951-d872f2087c98
* Implement ScopedFD in terms of ScopedGeneric.brettw@chromium.org2014-03-142-0/+82
| | | | | | | | | | | | | | | | | Move to a new file base/files/scoped_file.h. I will also add ScopedFILE to here (currently in file_util.h) later. I think there is a crash in the old code in content/browser/zygote_host/zygote_host_impl_linux.cc that this patch should fix. The old ScopedFD took the address of something in a vector that is being modified. I removed SafeScopedFD from content/common/sandbox_linux/sandbox_linux.cc since base's ScopedFD not CHECKs on close failure (this is a more recent addition). BUG= R=agl@chromium.org, viettrungluu@chromium.org Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257001 Review URL: https://codereview.chromium.org/191673003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257179 0039d316-1c4b-4281-b951-d872f2087c98
* Revert of Implement ScopedFD in terms of ScopedGeneric. ↵thakis@chromium.org2014-03-142-82/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://codereview.chromium.org/191673003/) Reason for revert: Doesn't build on android: FAILED: /mnt/data/b/build/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/base/memory/base.discardable_memory_allocator_android.o.d -DV8_DEPRECATION_WARNINGS -DBLINK_SCALE_FILTERS_AT_RECORD_TIME -D_FILE_OFFSET_BITS=64 -DNO_TCMALLOC -DDISABLE_NACL -DCHROMIUM_BUILD -DCOMPONENT_BUILD -DUSE_LIBJPEG_TURBO=1 -DENABLE_WEBRTC=1 -DUSE_PROPRIETARY_CODECS -DENABLE_CONFIGURATION_POLICY -DENABLE_NEW_GAMEPAD_API=1 -DDISCARDABLE_MEMORY_ALWAYS_SUPPORTED_NATIVELY -DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DENABLE_EGLIMAGE=1 -DENABLE_AUTOFILL_DIALOG=1 -DCLD_VERSION=1 -DENABLE_PRINTING=1 -DENABLE_MANAGED_USERS=1 -DUSE_OPENSSL=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DBASE_IMPLEMENTATION -DANDROID -D__GNU_SOURCE=1 -DUSE_STLPORT=1 -D_STLP_USE_PTR_SPECIALIZATIONS=1 '-DCHROME_BUILD_ID=""' -DHAVE_SYS_UIO_H -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -D_DEBUG -Igen/base -I../../third_party/android_tools/ndk/sources/android/cpufeatures -I../.. -fstack-protector --param=ssp-buffer-size=4 -Werror -fno-exceptions -fno-strict-aliasing -Wall -Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe -fPIC -Wheader-hygiene -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing -Wno-reserved-user-defined-literal -Wno-deprecated-register -Xclang -load -Xclang /mnt/data/b/build/slave/Android_Clang_Builder__dbg_/build/src/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.so -Xclang -add-plugin -Xclang find-bad-constructs -Xclang -plugin-arg-find-bad-constructs -Xclang check-url-directory -fcolor-diagnostics -Wexit-time-destructors -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -mthumb -no-integrated-as -B/mnt/data/b/build/slave/Android_Clang_Builder__dbg_/build/src/third_party/android_tools/ndk//toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin -ffunction-sections -funwind-tables -g -fstack-protector -fno-short-enums -Wa,--noexecstack -D__compiler_offsetof=__builtin_offsetof -Dnan=__builtin_nan -target arm-linux-androideabi -mllvm -arm-enable-ehabi --sysroot=/mnt/data/b/build/slave/Android_Clang_Builder__dbg_/build/src/third_party/android_tools/ndk//platforms/android-14/arch-arm -I/mnt/data/b/build/slave/Android_Clang_Builder__dbg_/build/src/third_party/android_tools/ndk//sources/cxx-stl/stlport/stlport -Os -g -fomit-frame-pointer -fdata-sections -ffunction-sections -funwind-tables -g0 -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -Wsign-compare -std=gnu++11 -Wno-implicit-exception-spec-mismatch -Wno-abi -c ../../base/memory/discardable_memory_allocator_android.cc -o obj/base/memory/base.discardable_memory_allocator_android.o ../../base/memory/discardable_memory_allocator_android.cc:84:25:error: no matching function for call to 'mmap' void* const address = mmap( ^~~~ /mnt/data/b/build/slave/Android_Clang_Builder__dbg_/build/src/third_party/android_tools/ndk//platforms/android-14/arch-arm/usr/include/sys/mman.h:47:15: note: candidate function not viable: no known conversion from 'base::ScopedFD' (aka 'ScopedGeneric<int, internal::ScopedFDCloseTraits>') to 'int' for 5th argument extern void* mmap(void *, size_t, int, int, int, off_t); ^ 1 error generated. Original issue's description: > Implement ScopedFD in terms of ScopedGeneric. > > Move to a new file base/files/scoped_file.h. I will also add ScopedFILE to here (currently in file_util.h) later. > > I think there is a crash in the old code in content/browser/zygote_host/zygote_host_impl_linux.cc that this patch should fix. The old ScopedFD took the address of something in a vector that is being modified. > > I removed SafeScopedFD from content/common/sandbox_linux/sandbox_linux.cc since base's ScopedFD not CHECKs on close failure (this is a more recent addition). > > BUG= > R=agl@chromium.org, viettrungluu@chromium.org > > Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=257001 TBR=viettrungluu@chromium.org,agl@chromium.org,brettw@chromium.org NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/197873014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257005 0039d316-1c4b-4281-b951-d872f2087c98
* Implement ScopedFD in terms of ScopedGeneric.brettw@chromium.org2014-03-142-0/+82
| | | | | | | | | | | | | | | Move to a new file base/files/scoped_file.h. I will also add ScopedFILE to here (currently in file_util.h) later. I think there is a crash in the old code in content/browser/zygote_host/zygote_host_impl_linux.cc that this patch should fix. The old ScopedFD took the address of something in a vector that is being modified. I removed SafeScopedFD from content/common/sandbox_linux/sandbox_linux.cc since base's ScopedFD not CHECKs on close failure (this is a more recent addition). BUG= R=agl@chromium.org, viettrungluu@chromium.org Review URL: https://codereview.chromium.org/191673003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@257001 0039d316-1c4b-4281-b951-d872f2087c98
* Move more file_util functions to base namespace.brettw@chromium.org2014-03-131-1/+1
| | | | | | | | TBR=jam Review URL: https://codereview.chromium.org/189333004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@256863 0039d316-1c4b-4281-b951-d872f2087c98
* Fix IWYU in base/files/file.htnagel@chromium.org2014-03-091-3/+2
| | | | | | | | | | | | | | | The other changes follow from that. BUG=82098 TBR=haruki@chromium.org (for chrome/browser/chromeos/drive/drive_file_system_util.h) TBR=hidehiko@chromium.org (for chrome/browser/chromeos/drive/webkit_file_stream_writer_impl.h) TBR=noamsml@chromium.org (for chrome/browser/local_discovery/storage/privet_filesystem_attribute_cache_unittest.cc) TBR=rvargas@chromium.org (for device/hid/hid_connection_linux.cc) TBR=clamy@chromium.org (for net/disk_cache/simple/simple_test_util.cc) Review URL: https://codereview.chromium.org/184583008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@255841 0039d316-1c4b-4281-b951-d872f2087c98
* Handle errors properly in FileUtilProxy::CreateTemporary.davidben@chromium.org2014-03-081-1/+10
| | | | | | | | | | | | If creating the temporary file failed, don't try to open it. If we can't open it for some reason, delete the temporary so the caller can assume strong exception safety and not have to delete the file on error. BUG=none Review URL: https://codereview.chromium.org/183003009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@255767 0039d316-1c4b-4281-b951-d872f2087c98
* Implement File::WriteAtCurrentPos for Windowsrvargas@chromium.org2014-03-072-15/+45
| | | | | | | | | BUG=145873, 322664 R=cpu@chromium.org Review URL: https://codereview.chromium.org/183333004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@255622 0039d316-1c4b-4281-b951-d872f2087c98
* Move WriteFile and WriteFileDescriptor from file_util to base namespace.brettw@chromium.org2014-03-062-7/+6
| | | | | | | | | R=viettrungluu@chromium.org TBR=viettrungluu Review URL: https://codereview.chromium.org/184563006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@255418 0039d316-1c4b-4281-b951-d872f2087c98
* Fix base/files/OWNERS syntaxtnagel@chromium.org2014-03-041-2/+1
| | | | | | | | BUG=none Review URL: https://codereview.chromium.org/183093009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@254756 0039d316-1c4b-4281-b951-d872f2087c98
* Base: Don't check for thread restrictions when closing a file doesn't do IO.rvargas@chromium.org2014-02-213-4/+10
| | | | | | | | | | | Also, clarify the File API a little more. BUG=322664 R=thakis@chromium.org Review URL: https://codereview.chromium.org/172673002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@252585 0039d316-1c4b-4281-b951-d872f2087c98
* GN: Change gen command syntax, support relative dirs.brettw@chromium.org2014-02-191-0/+7
| | | | | | | | | | | | | | | | This removes the default "gen" command so that "gn" by itself does nothing (it prints a short help message). The "gen" command now takes as an argument the output directory to use, and I removed the --output flag except for the "gyp" command (which will be needed until we update gyp_chromium). Updates the base build file to keep in sync with recent changes. True relative directories are now supported, so that the directories given to the gen command can be relative to the current one. It also supports relative directories for the desc and refs command. This allows you to be in the base directory and say "gn desc :base" and it will resolve the ":base" label relative to the current directory in the source tree. R=dpranke@chromium.org Review URL: https://codereview.chromium.org/165823003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@252040 0039d316-1c4b-4281-b951-d872f2087c98
* Convert Media Galleries to use base::Filervargas@chromium.org2014-01-273-61/+69
| | | | | | | | | | | | | | | Unfortunately, this brings in changes to webkit/browser/fileapi, and once that changes, a lot of files have to be updated. The bright side is that most of the collateral changes are just trivial renaming of PlatformFileError -> File::Error and PlatformFileInfo -> File::Info BUG=322664 Review URL: https://codereview.chromium.org/145303002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@247301 0039d316-1c4b-4281-b951-d872f2087c98
* Removes MessageLoop::TYPE_XXX where possiblesky@chromium.org2014-01-151-3/+2
| | | | | | | | | | | | This is part of attempting to get rid of MessageLoop::Type enum. BUG=none TEST=none R=darin@chromium.org Review URL: https://codereview.chromium.org/136683004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@244996 0039d316-1c4b-4281-b951-d872f2087c98
* Convert most of base and net to use base::Filervargas@chromium.org2014-01-091-10/+6
| | | | | | | | | BUG=322664 R=thakis@chromium.org Review URL: https://codereview.chromium.org/125643002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@243852 0039d316-1c4b-4281-b951-d872f2087c98
* Base: Rename File::error() to File::error_details()rvargas@chromium.org2014-01-085-22/+22
| | | | | | | | | BUG=322664 R=thakis@chromium.org Review URL: https://codereview.chromium.org/126453004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@243676 0039d316-1c4b-4281-b951-d872f2087c98
* Convert base::file_util to use File instead of PlatformFile.rvargas@chromium.org2014-01-075-21/+43
| | | | | | | | | | | BUG=322664 R=brettw@chromium.org TBR=darin@chromium.org Review URL: https://codereview.chromium.org/101143006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@243235 0039d316-1c4b-4281-b951-d872f2087c98
* Convert base::MemoryMappedFile to use File instead of PlatformFile.rvargas@chromium.org2014-01-039-110/+123
| | | | | | | | | | | | | | | | | | | This also modifies consumers of MemoryMappedFile and fixes double handle close on MediaFileChecker, media_file_checker_unittest and data_pack_unittests. BUG=322664 TEST=unit tests R=cpu@chromium.org, dalecurtis@chromium.org (media) TBR (owners): tony@chromium.org (resource) jochen@chromium.org (chrome-content) thakis@chromium.org (base) Review URL: https://codereview.chromium.org/109273002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@242937 0039d316-1c4b-4281-b951-d872f2087c98
* Add FilePath::FinalExtension() to avoid double extensions (.tar.gz) for file ↵davidben@chromium.org2013-12-093-19/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | selector Windows and OS X file selectors break badly on double-extensions. GTK and Chrome OS handle it slightly better, but CrOS has a slight bug and GTK's handling of file extensions is minimal, so not a whole lot changed. See https://codereview.chromium.org/4883003/#msg14 for full analysis of platform behavior. There is some logic that does benefit from long extensions (renaming "foo.tar.gz" to "foo (1).tar.gz" instead of "foo.tar (1).gz"), and some other callers store state based on extension, so rather than changing FilePath::Extension, add a new FilePath::FinalExtension and change SelectFileDialog callers to use it. Also work around a problem in NSSavePanel when saving "foo.tar.gz" with extensions hidden. TEST=FilePath.Extension, FilePath.Extension2 FilePath.RemoveExtension Enabling "Ask where to save each file before downloading"; saving a tar.gz doesn't result in weird confirmation prompt on OS X, with or without "Show all filename extensions" enabled in Finder. BUG=83084 Review URL: https://codereview.chromium.org/4883003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239505 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 239400 "Revert 239280 "Move more file_util functions to b..."thakis@chromium.org2013-12-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broke all bots 9_9 > Revert 239280 "Move more file_util functions to base namespace." > > dbus_unittests started fialing on Linux Tests (dbg)(2) and Linux Tests (dbg)(2)(32). > This CL is the only in the intersection of CLs in the first failing build on > the two builders, so giving a speculative revert a try (rlarocque already > tried a clobber, it didn't help). > > http://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%282%29/builds/41806 > http://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%282%29%2832%29/builds/8544 > > > > Move more file_util functions to base namespace. > > > > TBR=sky > > > > Review URL: https://codereview.chromium.org/109043002 > > TBR=brettw@chromium.org > > Review URL: https://codereview.chromium.org/105823009 TBR=thakis@chromium.org Review URL: https://codereview.chromium.org/100923007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239401 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 239280 "Move more file_util functions to base namespace."thakis@chromium.org2013-12-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | dbus_unittests started fialing on Linux Tests (dbg)(2) and Linux Tests (dbg)(2)(32). This CL is the only in the intersection of CLs in the first failing build on the two builders, so giving a speculative revert a try (rlarocque already tried a clobber, it didn't help). http://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%282%29/builds/41806 http://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%282%29%2832%29/builds/8544 > Move more file_util functions to base namespace. > > TBR=sky > > Review URL: https://codereview.chromium.org/109043002 TBR=brettw@chromium.org Review URL: https://codereview.chromium.org/105823009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239400 0039d316-1c4b-4281-b951-d872f2087c98
* Move more file_util functions to base namespace.brettw@chromium.org2013-12-071-3/+3
| | | | | | | | TBR=sky Review URL: https://codereview.chromium.org/109043002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@239280 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-03-14 03:32:02 +0000