Кът на програмиста...

The Dragon · Post by **The Dragon** » Fri Mar 05, 2010 4:33 pm

http://www.inc.com/magazine/20100301/le ... fline.html

Damn ... its about time. Беше се превърнал в димяща купчина лайна последните 2-3 години.

dellusion · Post by **dellusion** » Wed Mar 17, 2010 10:38 am

Добре, имам ебати странния проблем. Начи имам file _x.xml и един ант, дето прави copy _x.xml то x.xml. Само че операцията не минава, гърми със

Failed to copy _x.xml to x.xml due to FileNotFoundException x.xml (Access is denied)

Изглежда не успява да създаде втория файл, ама не виждам защо. На WinXP съм, нямам някви специални permissions.
По едно време в пристъп на отчаяние си дефрагментирах харда и това зе че мина, ама следващия път като пробвах пак гръмна. Другия начин, по който оправям проблема е да изтрия _x.xml преди пусна билда и след като го пусна, да върна файла. И двата начина не си обяснявам защо помагат, освен това и двата са смотани и не може да продължава така. Идеи?

Roamer · Post by **Roamer** » Wed Mar 17, 2010 10:59 am

Начинът за достъп до файлове под Windows е доста странен в някои отношения във връзка с заключването на използвани файлове. В частност, не можеш да изтриеш или изкопираш нещо ново върху файл, който в момента друга програма държи отворена. Исторически причини, много шашави, много шашав дизайн още на първите файлови системи FAT, ама и досега трябва да се примиряваме със семантиката.

Възможно ли е в този момент да има друг процес, който да е отворил файла x.xml? Дори само за четене да го е отворил, пак е достатъчно, за да откаже Windows да запише нещо ново върху него.

dellusion · Post by **dellusion** » Wed Mar 17, 2010 11:08 am

Възможно е(ма не виждам кое е), ама виж, то се оплаква, че не може да достъпи новия файл, не оригиналния.

Roamer · Post by **Roamer** » Wed Mar 17, 2010 11:10 am

Така де, и аз за новия питам - нали оригиналният е _x.xml, а новият е x.xml? И аз именно за x.xml питам.

Добавено: Примерно ако това е някаква deploy-ната Java-щуротия, някой Tomcat или нещо такова да е захапал xml-файловете просто ей-така, щот' може? Или знам ли и аз.

Добавено пак: Макар че не би трябвало да е това де - то идеята на deploy-ването е Tomcat-ът да си ги премести на ново място, така че само той да си ги пипа и държи, а при нормален build на теб да не ти се налага да пипаш *неговите* копия... освен ако нещо друго не е наред с целия setup при теб.

bsb · Post by **bsb** » Wed Mar 17, 2010 11:11 am

Само две думи - Process Monitor.

dellusion · Post by **dellusion** » Wed Mar 17, 2010 11:17 am

Roamer, еми няма deploy, само build и не виждам какъв ше да е тоя процес, дето захапва файла милисекунда след създаването му. По едно време си мислех за тоя индексиращия service, ама го изключх и пак същото.

Междо другото забравих да спомена, че с Ант 1.7.1 нямам проблем, това е само при 1.8.0

Post by **Moridin** » Wed Mar 17, 2010 11:28 am

Roamer wrote:Начинът за достъп до файлове под Windows е доста странен в някои отношения във връзка с заключването на използвани файлове. В частност, не можеш да изтриеш или изкопираш нещо ново върху файл, който в момента друга програма държи отворена. Исторически причини, много шашави, много шашав дизайн още на първите файлови системи FAT, ама и досега трябва да се примиряваме със семантиката.

Възможно ли е в този момент да има друг процес, който да е отворил файла x.xml? Дори само за четене да го е отворил, пак е достатъчно, за да откаже Windows да запише нещо ново върху него.

???
не е ли най-естественото поведение, ако друга програма държи файла отворен, да не се презаписва върху него? concurrency алабала...

Roamer · Post by **Roamer** » Wed Mar 17, 2010 11:44 am

Ми не - не и когато говорим за пълна замяна на цялото съдържание на файл с нещо ново.

При всички свестни операционни системи (и файлови системи) опитът да направиш delete(existing) изтрива *името* на файла от *директорията*, проверява дали някой процес не държи файла отворен и, ако няма никой, изтрива съдържанието на файла от диска. Ако има процес, който държи файла отворен, той може да си го достъпва идеално по файлов дескриптор (ОС си има вътрешна таблица, та си знае в кой inode е файлът) и този процес си чете и пише колкото си иска, а после затваря файла и ОС изтрива съдържанието му, защото някой вече е казал, че този файл наистина не е нужен.

При overwriting на съществуващ файл *винаги* (освен под Windows...) безопасният начин е да направиш create(tempfile), write-to(tempfile), rename(tempfile, existing), така че в никой момент съдържанието на файла existing да не е непълно/частично и т.н. - *именно* заради concurrency - защото друга програма може да отвори existing за четене (или дори изпълнение), преди ти да си записал в него всичко, което ти трябва. В тази ситуация една "нормална" ОС ще позволи на съществуващи процеси, които държат файла existing отворен (за четене, за писане или дори за изпълнение) да си запазят отворения файлов дескриптор и да си работят спокойно със старото съдържание на файла, докато не го затворят и евентуално отворят наново. В момента, в който и последният процес затвори стария файл, ОС изтрива съдържанието му и от диска - но много преди това вече процеси, които отварят файла existing, ще виждат новото съдържание.

Елементарен пример за това е инсталиране на нова версия на binary executable, което изпълняваш в момента - дали ще е демонче за някой сървър, дали ще е просто /bin/sh или /usr/bin/login, *трябва* да можеш да го подмениш с нова версия, без да се налага да правиш "shutdown partially, install updates and then restart"

Някак си... понякога е добре да знаеш, че можеш да си оправиш проблем с executable или дори с конфигурационен файл, без да рестартираш цялата система или дори услугата, която ползва файла - някак си помага за намаляване на downtime.

Ако някоя програма *действително* иска никой да не й пипа файла, докато тя си работи с него, за тази цел си има file locking syscalls, които са си работели прекрасно от време оно.

Мдааааааааааааа... а имаше една лекция по Мрежова сигурност, която посветихме на отговаряне на въпроси от студенти за неща, които не са им ясни за последния тест след два дни. Имаше един човек, който зададе въпрос... имаше един отвеян мррмот, който започна да отговаря на въпроса, установи, че част от отговора изисква познания за on-disk структурата на различни файлови системи и се отплесна да говори 40 минути за различните файлови системи - което нямаше много общо с теста

Маниакса ме гледаше с интерес през цялото време, а към тридесетата минута портиерът влезе да ми обясни, че вече е време да пускаме студентите и да заключваме залата, щото той иска да пуска алармата, ама аз си продължих, докато си кажа приказката - и дори май имаше студенти, на които им беше интересно, а за поне трима-четирима съм сигурен, че след това им е било и полезно

Е, всеки си има любими теми за философстване...

bsb · Post by **bsb** » Wed Mar 17, 2010 12:55 pm

Тоест при "нормалните" ОС си пиша текстовия документ на сървъра, друг потребител обаче решава, че този документ вече не му трябва, и го изтрива. Аз си затварям документа, после тръгвам да го отварям и той вече липсва, така ли? Защото от това обяснение, което си дал, оставам с точно такова впечатление: "после затваря файла и ОС изтрива съдържанието му, защото някой вече е казал, че този файл наистина не е нужен".

Roamer · Post by **Roamer** » Wed Mar 17, 2010 1:45 pm

Почти така

Няколко неща:

1. Като казваш "друг потребител"... ммм, това за мен значи "друг системен акаунт", което веднага ми запалва червената лампичка - другите системни акаунти просто нямат право да трият, презаписват и дори четат файловете, които аз създавам

Е, освен ако не ги създавам в специални директории за временни файлове де, но пък там пак аз съм си виновен, ако не съм се погрижил за това да не могат да ги четат - а дори и там, при "нормалните" ОС директориите /tmp и /var/tmp имат вдигнат sticky bit, който за директория означава "никой не може да *изтрие* файл, принадлежащ на друг". Може да го прочете, може да пише в него - разбира се, и двете са ако другият е разрешил това с правата за достъп до файла - но не може да го изтрие.

2. Дори да имаш предвид "друга сесия на същия логнат потребител" или дори "друг човек, който има достъп до същия акаунт" - е, това вече е друга ситуация и не е работа на ОС да се опитва да даде техническо решение на не-технически въпрос (в случая почти политически в смисъл на policy, не politics - правилата за използване на споделения акаунт, които хората си уточняват помежду си). Ако е друга сесия на същия потребител - ми кат' е идиот, да си трие файловете

Ако е друг човек, който има достъп до акаунта - тогава е въпрос на policy - откъде-накъде той ще ми трие файлове, за които не знае какво представляват, без да се поинтересува?

Това съвсем сериозно де.

3. А като оставим всичко това настрана...

На практика никой текстов редактор не държи непрекъснато отворен файла, който редактира, и не прави промените директно в него. И тук имам предвид всякакви текстови редактори под всякакви ОС - повечето прочитат целия файл в паметта, правят си временен буферен файл, в който записват промените (под Windows това се вижда много ясно с файлове ~tmpXBDHDH.doc в същата директория, под Unix различните редактори ползват ".fname.swp" или "fname~" или две-три други почти стандартни имена), и накрая - когато стане нужда да бъдат записани промените - редакторът отваря файла отново и тогава пише в него. Има изключения, разбира се, но действително повечето редактори работят така, така че промените няма да бъдат загубени - най-много редакторът да изквичи "Опааа, файлът е променен откак аз го гледах за последен път, сигурен ли си, че исакш да пишем в него?" (и, да, изтрит файл за мен също е променен файл

)

И тъй. Да, при първо сблъскване с тази идея тя изглежда малко странна, но впоследствие, когато човек малко посвикне с нея, открие добрите й страни и се научи как да заобикаля не-толкова-добрите, започва да се чуди много сериозно как е можел да работи изобщо с ОС, за която името на файла е единственият му идентификатор

(да, да, знам, при NTFS и т.н. вече дори това не е точно така, но системните функции продължават да се държат така 1. защото не винаги се ползва NTFS и 2. защото програмите в продължение на 20 години са били свикнали на това) Аз лично съм адски доволен от две от добрите страни - едната вече я споменах - мога по всяко време да заместя отворен файл с rename() върху него; другата е, че програмата може да си създаде прекрасен временен файл, като създаде файл, остави си го отворен и *веднага го изтрие* - тя самата си пише и чете в него, а няма нужда да се грижи за това да го изтрива при всякакви неприятни ситуации, свързани със завършване - ОС ще си го изтрие сама. Звучи малко convoluted, но понякога е много полезно.

Corwin · Post by **Corwin** » Mon Mar 22, 2010 2:23 pm

Абе някой занимавал ли се е с парсване на имиджи. Трябва ми за нещо горе-долу просто - взимаш примерно черно-бяла картинка и ми трябват координатите на границата между черното и бялото...

Post by **Moridin** » Mon Mar 22, 2010 2:26 pm

Е то това "парсване" на имиджи ли е

търси за едж-детекшън алгоритми. специално в този случай нещата са прости и би трябвало всичко да ти работи. минаваш едни градиенти там по пикселите и си готов

Corwin · Post by **Corwin** » Mon Mar 22, 2010 2:35 pm

Еба ли го още кво е, за тва питам.

thunder · Post by **thunder** » Mon Mar 22, 2010 3:13 pm

Аз съм писал нещо такова - не е много тръудно ако е черно бяла картинка. Мисля че gif картинките си държаха информацията по доста лесен за обработка начин - просто кодовете на цветовете на пикселите един след друг, като файла започва с хедър, който държи информация за това колко е голяма картинката и какви цветове съдържа.

Та на това нещо не е много трудно да му измислиш алгоритъм, който да се научи да чете какво има вътре (аз писах един, който разпознаваше букви).

Може да бъркам gif с bmp

PNG нямам идея, а JPG е тотално в джаза. Помня че преминавах от един формат картинка в друг, но не помня кои

Кът на програмиста...

Who is online