Search Results

Search found 5 results on 1 pages for 'justjeff'.

Page 1/1 | 1 

• what can cause a folder to become indestructible?

  - by JustJeff

  I have a directory that I want to delete, but windows (xp sp3) is giving me the run-around and the folder is now effectively indestructible. Attempts to open the folder, either via explorer or cmd.exe are met with 'd:/temp/foo Is Not Accessible. Access is denied'. Attempts to delete the folder result in 'Cannot delete foo: The directory is not empty' So I can't delete it because supposedly it's not empty, but windows won't let me in it for some reason, so I can't clean it out first. There's nothing in it of consequence, and basically I just want to delete it at this point. Thinking that some other process must have a lock on it, I used the SysInternals 'handles' and Process Explorer to look for open handles with the directory name. These turned up no matches. (The directory name is not actually 'foo', it is something more unique but 'foo' is easier to type here). I put the machine through a restart, and the problem persists. I did a search for the folder name with regedit, to see what other apps might be aware of it. No match. The properties dialog was mildly interesting. The Read-Only attribute is 'semi-checked', i.e., the grayish check mark you get when some parts are and some parts aren't. Naturally I immediately unchecked this, and tried to delete the folder. No go. Opening properties again reveals the gray check mark next to Read-Only has returned. All the stats, size, size on disk, files, folders, all these are zero. There do not appear to be any shares on the folder, so that's not it either. Finally, I tried opening the partition's properties, and running the Tools/Error Checking utility. This didn't turn up any problems either. Fwiw, this directory was created by [a popular gui zip tool] when I tried to unpack a tar-and-zipped archive created on another system with command line utils. The archive was definitely corrupt, but I've never seen such a file do anything worse than crash the zip app, and certainly never leave permanent glitches in the file system. So what else can possibly be going on to make this folder behave this way?

  Read the article

• Is NFS capable of preserving order of operations?

  - by JustJeff

  I have a diskless host 'A', that has a directory NFS mounted on server 'B'. A process on A writes to two files F1 and F2 in that directory, and a process on B monitors these files for changes. Assume that B polls for changes faster than A is expected to make them. Process A seeks the head of the files, writes data, and flushes. Process B seeks the head of the files and does reads. Are there any guarantees about how the order of the changes performed by A will be detected at B? Specifically, if A alternately writes to one file, and then the other, is it reasonable to expect that B will notice alternating changes to F1 and F2? Or could B conceivably detect a series of changes on F1 and then a series on F2? I know there are a lot of assumptions embedded in the question. For instance, I am virtually certain that, even operating on just one file, if A performs 100 operations on the file, B may see a smaller number of changes that give the same result, due to NFS caching some of the actions on A before they are communicated to B. And of course there would be issues with concurrent file access even if NFS weren't involved and both the reading and the writing process were running on the same real file system. The reason I'm even putting the question up here is that it seems like most of the time, the setup described above does detect the changes at B in the same order they are made at A, but that occasionally some events come through in transposed order. So, is it worth trying to make this work? Is there some way to tune NFS to make it work, perhaps cache settings or something? Or is fine-grained behavior like this just too much expect from NFS?

  Read the article

• How to get desired FireFox last tab behavior?

  - by JustJeff

  All tabs should be the same; so if any of the have a 'close' button, they all should, including the last tab. I see no reason that a tab's close button should suddenly vanish simply b/c that tab has become the last one open. If I have N tabs open, and park the mouse over the left-most tab's close button, this vanishing close button trick means now I have to make a large mouse move to get to the app's close button. Unsat. Mouse moves = too many milliseconds wasted. Closing the last tab should NOT take me to my home page, or any other page whatsoever. I want the browser to close with the last tab. I do not expect or want "new tab" behavior when I click a Close button. Now, I've gone into about:config and played with browser.tabs.closeWindoWithLastTab, but this setting oversteps its purpose; while it does make the browser close, for some inexplicable reason, it also suppresses the last tab's close button! I have tried the "last tab close button" add-on, and while this does restore the close button, the add-on oversteps by taking the liberty of turning closeWindowWithLastTab off. Is there some way out of this pickle? Is it too hard to just code things to provide simple, orthogonal actions, so that everybody can config the UI to their liking, and not just to a few pre-fab configurations that the developers think everyone should like? Btw, FF 13.0.1 on ms windows

  Read the article

• Unit testing UDP socket handling code

  - by JustJeff

  Are there any 'good' ways to cause a thread waiting on a recvfrom() call to become unblocked and return with an error? The motivation for this is to write unit tests for a system which includes a unit that reads UDP datagrams. One of the branches handles errors on the recvfrom call itself. The code isn't required to distinguish between different types of errors, it just has to set a flag. I've thought of closing the socket from another thread, or do a shutdown on it, to cause recvfrom to return with an error, but this seems a bit heavy handed. I've seen mention elsewhere that sending an over-sized packet would do it, and so set up an experiment where a 16K buffer was sent to a recvfrom waiting for just 4K, but that didn't result in an error. The recvfrom just return 4096, to indicate it had gotten that many bytes.

  Read the article

• Is NFS capable of preserving order of operations?

  - by JustJeff

  I have a diskless host 'A', that has a directory NFS mounted on server 'B'. A process on A writes to two files F1 and F2 in that directory, and a process on B monitors these files for changes. Assume that B polls for changes faster than A is expected to make them. Process A seeks the head of the files, writes data, and flushes. Process B seeks the head of the files and does reads. Are there any guarantees about how the order of the changes performed by A will be detected at B? Specifically, if A alternately writes to one file, and then the other, is it reasonable to expect that B will notice alternating changes to F1 and F2? Or could B conceivably detect a series of changes on F1 and then a series on F2? I know there are a lot of assumptions embedded in the question. For instance, I am virtually certain that, even operating on just one file, if A performs 100 operations on the file, B may see a smaller number of changes that give the same result, due to NFS caching some of the actions on A before they are communicated to B. And of course there would be issues with concurrent file access even if NFS weren't involved and both the reading and the writing process were running on the same real file system. The reason I'm even putting the question up here is that it seems like most of the time, the setup described above does detect the changes at B in the same order they are made at A, but that occasionally some events come through in transposed order. So, is it worth trying to make this work? Is there some way to tune NFS to make it work, perhaps cache settings or something? Or is fine-grained behavior like this just too much expect from NFS?

  Read the article

1