Вопросы Теги

Как можно сказать, является ли каталог записываемым в Objective C?

Другой вариант - удалить хеш и сохранить его в хранилище сеансов для извлечения при перезагрузке: 

var newUrl = location.href + '#myHash';
var splitUrl = newUrl.split('#');
newUrl = splitUrl[0];
if (splitUrl[1]){
    sessionStorage.savedHash = splitUrl[1];
}
location.href = newUrl;

, а затем в верхней части страницы вы можете получить следующий код: 

var savedHash = sessionStorage.savedHash;
if (savedHash){
    delete sessionStorage.savedHash;
    location.hash = savedHash;
}
5
задан smorgan 27 October 2009 в 13:34
поделиться

3 ответа

Это опасно, потому что что угодно может взять эту блокировку, поэтому трудно или невозможно предотвратить тупиковую ситуацию.

Раньше на эту тему была статья («Не блокируйте объекты типа!» статья Dr. GUI) с некоторыми комментариями Рико Мариани. Судя по всему, статья больше не доступна напрямую, но есть «зеркала», плавающие вокруг, в том числе на http://bytes.com/topic/c-sharp/answers/249277-dont-lock-type-objects .

Вот отрывок:

Основная проблема здесь в том, что вам не принадлежит объект типа, и вы не знаете, кто еще может получить к нему доступ. В общем, очень плохая идея полагаться на блокировку объекта, который вы не создавали и не знаете, кто еще может получить доступ. Это ведет к тупику. Самый безопасный способ - заблокировать только частные объекты.

Но подождите; это даже хуже, чем все это. Как оказалось, в текущих версиях среды выполнения .NET объекты типов иногда используются совместно между доменами приложений (но не между процессами). (Обычно это нормально, поскольку они неизменяемы.) Это означает, что ДРУГОЕ ПРИЛОЖЕНИЕ, работающее даже в другом домене приложения (но в том же процессе), может заблокировать ваше приложение, получив блокировку объекта типа, который вы хотите заблокировать. и никогда не выпускать его. И было бы легко получить доступ к этому объекту типа, потому что у объекта есть имя - полное имя типа! Помните, что блокировка / SyncLock блокирует (это вежливое слово для обозначения зависаний) до тех пор, пока не сможет получить блокировку. Очевидно, что очень плохо полагаться на блокировку, которую другая программа или компонент может заблокировать и привести к тупиковой ситуации.

1
ответ дан 13 December 2019 в 05:37
поделиться

You want 

-attributesOfItemAtPath:error:.

-jcr

3
ответ дан 13 December 2019 в 05:37
поделиться

Edit: Looks like inkjet figured out why I was getting inconsistent results. Marking his as the correct answer.

Weird. I tried isWriteableAtPath before and it didn't seem to work as I expected, but now with an isolated test does.

NSFileManager *fm = [NSFileManager defaultManager];
NSLog(@"%d /private/ writeable?", [fm isWritableFileAtPath:@"/private/"]);
NSLog(@"%d /Applications/ writeable?", [fm isWritableFileAtPath:@"/Applications/"]);
NSLog(@"%d /Users/MYUSERNAME/ writeable?", [fm isWritableFileAtPath:@"/Users/MYUSERNAME/"]);

Prints

0 /private/ writeable?
1 /Applications/ writeable?
1 /Users/MYUSERNAME/ writeable?
5
ответ дан 13 December 2019 в 05:37
поделиться