/f /r
What is the difference between fixing and recovering bad sectors?
/c
Eli5 "Skips the checking of cycles within the folder structure." Can someone explain this.
/i
Eli5 "Performs a simpler check of index entrie."
Also any info online that will explain the rest in detail would be most helpful.
/r tries to recover any readable part of the sector
to be totally honest, there is nothing like recovering the sector itself, if it failed once, it is almost certain to fail again so the utility marks it as unusable, in both /f and /r, but the later at least tries to read some thing first.
/c cycles happens when the folder A 'contains' folder B, that 'contains' A, of corse no one contains anything at that level, they are all lists of references, so this cycling could happens. Using this option reduce the time to check, but skip checking for this very specific kind of error, if you are not worring about it.
/i Well, every folder (and the partition itself) is a special file with lot of references, instead of checking if the referenced file id really there, and if it is readable, one could simply check if the index have any error in it's structure, and forget about the actual data.
Please look at the manual first
Related
I think I did some stupid thing by creating random data using some command dd if=/dev/urandom of=20GB.bin bs=1GB count=16 iflag=fullblock
in huge size. Actually I was testing the behaviors of something when disk is full.
However Now I wish to delete this. I deleted the dev/urandom folder hoping it will do something, but it seems nothing was deleted without making any difference.
I see some commands online like wipe and shred, However now my dev/urandom folder is deleted, so what exactly should I do now ?
Any kind of help will be great.
you saved the random numbers to 20GB.bin thus you can do rm 20GB.bin to remove it. /dev/urandom is a special file bound to a tool and does not save random files, but just creates them on the fly. Some other tools might depend on /dev/urandom so deleting this device file might let them crash.
I know variants on this have been asked before (e.g. https://groups.google.com/forum/#!topic/snakemake/4kslVBX2kew), but I don't see a definitive solution.
If I run a long-running and complex Snakemake pipeline with '--notemp' (maybe because I'm debugging), it would be really nice to be able to subsequently run a 'cleanup' command to delete anything that would automatically have been deleted on the first run without --notemp. Is there any easy way of doing this?
The way I'm doing this right now is to re-run after using '--forceall --touch', without '--notemp', such that everything just gets touched, and the temp files then get removed at the end. But it's not ideal to change all the timestamps. Is there a better way?
Jon
Since v5.0.0, --delete-temp-output achieves this.
--delete-temp-output
Remove all temporary files generated by the workflow. Use together with –dry-run to list files without actually deleting anything. Note that this will not recurse into subworkflows.
Default: False
I have a two broken VIs with front panels that open fine, but I can't edit or run them, or open theis block diagrams.
One of these was made as a replacement for the first when it started to have this problem. I need to at least find out how to avoid this problem in future, so I don't lose work on bigger VIs.
I'm not sure if it makes any difference, but I very recently upgraded to LabVIEW 2013.
Thank you in advance.
This is the error I get when I try to run them:
"
VI has a bad connection to or cannot find a subVI or external routine.
This VI has a bad connection to or cannot find a subVI or external routine but
it has no block diagram to show or fix the error. You must find or correct the
subVI or external routine. Check for more information in the Explain dialog box
in Get Info.
"
Before reverting to a previous version (using dropbox) I got a different error with one of them:
"
LabVIEW: Generic error.
An error occurred loading VI 'sweep harmonics first test.vi', LabVIEW load
error code 6: Could not load the block diagram.
"
One situation how this happened.
Sometime LabVIEW crashes, and it restart. After restart, LabVIEW will ask you to recover the autosaved code.
I personally always discard those autosaved code. If you do choose to recover autosaved code, there is a chance the recovered code is corrupted. Once you save corrupted code to disk, you are probably going to lose the ability to open/save the block diagram ever again.
Having a version control system is usually a way to avoid minimize the damage when LabVIEW crashes. At worst, you loose maybe an hour worth of work.
If you can't open Block Diagram of your VI, first check the suggestion by #Rodrigo - it is most likely just a "compiled" VI, which has Block Diagram removed.
If you think there is Block Diagram inside and it is just corruped - you may contact NI support. And if you want to look deeper by yourself, extract the VI to XML using pyLabview, and look into the XML - there you can modify every single part of the VI. For example, you may start removing parts until it starts working.
I wouldn't go into manual VI editing unless you have at least a dozen of affected files though. For a single file, it will be faster to re-create it in LabVIEW instead of trying to understand the internals. If many files are affected - may be worth finding the issue in one, as other files probably have the same glitch, so you can make a script which extracts, modifies and re-creates VIs automatically.
From the sound of it, I believe what happens is that you are trying to run the VI's created as "DATA" for an executable, instead of the actual source VI's.
When you build an executable LabVIEW creates a copy of all the Top Level VI's dependencies into the support (DATA) folder which should be in the same directory as your executable.
Try opening the VI's that are marked as not having a block diagram and navigate to File>>VI Properties to check the path from which the VI is being loaded. If it's not the original VI, you can just replace it.
When using the magic function %edit from QtConsole with IPython, the call does not block, and does not execute the saved code. It does however save a temporary file...
I think this is intended behavior due to GUI editors and uncertainty, and whatever that reason is for not being able to communicate with subprocess (pyZMQ?).
What do you suggest as the best way to mix %edit/%run magics?
I would not mind calling two different commands (one to edit, and one after I have saved and execution is safe). But those commands need a way to synchronize this target file location, or someone to persist storage, and probably need some crude form of predicatably generating filenames such that you can edit more than one file at a time, and execute in arbitrarily. Session persistence is not a must.
Would writing my own magic do any good? Hope we can %edit macros soon, that would do well enough to make it work.
you shoudl be able to do %edit filename.py and %run filename.py. The non blocking behavior is expected, and IIRC due to technical reason. Not unsurmountable but difficult.
You could define your own magic if you wish, improvement are welcomed.
Hope we can %edit macros soon, that would do well enough to make it work.
For that too, PR are welcomed. I guess as a workaround/option you can %load macro which would put macro on input n+1 , edit it and redefine it, that might be a good extension for a cell magic %%macro macroname
If you have some executable code on your input (from QtConsole), you can type
%edit 1-5
This fires the editor, creates a temporarily file (automatically managed), and loads your input lines. This is nearly enough, now how to retrieve the name of that temp file pragmatically?
I see the print statement on Stdout, but its not visible to QtConsole AFAIK. Could maybe redirect stdout to catch that line, but that may not be an option anyway if your doing something else with stdout.
If I could retrieve the full pathname that was just created, this would be cake. Store it where some magics will know how to find it. Then issue a followup command when ready,pops the name off the stack, loads it into a macro, and run. All this with 2 input commands and no names to remember (unless you want to find and use that macro again, but for 1 shot stuff...)
How do I catch or retrieve the path of that temporary file?
I need to prove that a VB.NET program that I wrote was written at a particular time.
(the reason is an academic integrity investigation where someone copied my code).
I have all the code on my disk including the debug and release folders, with my username in the build paths.
Are their addition things I could do, such as looking in the binaries?
If you use IL Disassembler to open the EXE/DLL, then select menu option View>Header, there is a field called "Time-date stamp" in the COFF/PE header. It's in binary format, and according to MSDN it is:
The low 32 bits of the time stamp of the image. This represents the date and time the image was created by the linker. The value is represented in the number of seconds elapsed since midnight (00:00:00), January 1, 1970, Universal Coordinated Time, according to the system clock.
First thing you should do it copy all of the data as it stands to another device - making sure you preserve all date times. Do not open or edit any of the files.
Each file will have three timestamps, when it was created, when it was last modified etc. These can be found using DIR /T
/T Controls which time field displayed or used for sorting
timefield C Creation
A Last Access
W Last Written
Get a listing of the directory like this:
DIR myrootdir /s /ah /as /tc > fileslist.txt
This will dump out all the files with creation times to a file called fileslist.txt
Also as #EricJ says : offer your disk as evidence - but like I said make a copy first. It would be best to make an image copy (windows backup) to an another drive first.
The investigators are going about this all the wrong way.
Any timestamp data can be faked, so the best way would be for them to sit down and ask detailed questions about how the code works, to both parties seperately.
Or to ask both parties to complete a small test project, again seperately - under exam conditions.
The one that copied the work wont understand what they copied most likely, and wont be able to reproduce something based on similar concepts.
The one who did write it - well unless they cheated to, they will understand it all in depth.