Are you able to rename a segment in VoltDB?
I have come across a recent issue where a segment has disappeared and below it, it looks like a command to rename the segment, I am very new to voltdb and would like to know if this command is legal?
Related
I accidentally ran this command while trying to remove an errant directory named \\ from my project directory. Quite a mistake I know. It pretty quickly began hitting permissioned files at which point I realized my mistake so I ctrl-c'ed out of there. I have all my important projects backed up but the command killed my development environment. Opening vim anywhere is crashing and throwing a segfault like so:
Vim: Caught deadly signal SEGV
Error detected while processing function <SNR>130_PollServerReady[7]..<SNR>130_Pyeval:Vim: Finished.
line 4:
Exception MemoryError: MemoryError() in <module 'threading' from '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.pyc'> ignored
[1] 6921 segmentation fault vim ~/dotfiles/.vimrc
My primary question for myself and anyone who commits a similar gaff is:
What, precisely does the double backslash // point to? What would be deleted first? Is there a logical first place to begin replacing util, configs, $PATH stuff etc?
Hopefully, this is clear and specific enough for SO.
cd // will take you to the root directory /.
rm performs a depth-first search, walking the results of the xfts_open call. find also traverses filesystems in this manner.
find / will list the files that exist. You can then use your knowledge of the expected structure to reverse the list that are missing.
Alternatively, you can use debugfs to help you get at the files.
This assumes that these commands will actually work. Realistically, your system is probably hosed. Deleting things in / will break your computer. Restoring from backup is probably the easiest way to return to a functional system. You can also try various utilities to recover recently erased files from your hard drive; if you plan on doing this, you should stop using your computer, as your hard drive currently treats many areas as free space (since you told it to) which recently held files in / and it could start writing to those areas.
In Linux, and I believe other *nix flavours, an extra slash in a path is simply ignored. Thus, a//b is the same as a/b and // is the same as /. I hope you didn't run this as a superuser...
I think this is related to iCloud Drive in some way, but I have not investigated.
I'm trying to track down an issue with Perl's rename on macOS using the Apple Filesystem (APFS). I've been able to replicate this with perls back to at least 5.12.3 but all of mine are compiled with Apple LLVM version 9.1.0 (clang-902.0.39.1). Those same perls do not have this problem with FAT or HFS+ filesystems. I haven't noticed this problem anywhere else.
Run it the first time. I end up with a Changes and a Changes.bak. That's exactly what I expected.
Run it again. You end up with Changes and Changes 3 file. There is no Changes.bak. This is odd.
Run it again. I end up with a Changes file, Changes.bak, and Changes 3.
Run it again. I end up with a Changes file, Changes 3, and Changes 4. Again, there's no Changes.bak.
If I remove the print line I can't get this to present ("Doctor, it hurts when I move my arm like this").
I re-ordered the file handle opens and closes but that didn't seem to fix anything.
I figure there's something happening at the filesystem level. So I really have two questions:
Is this a bug and at what level? Is the rename not guaranteed to finish whatever it needs to do before I start messing with file handles?
I want to read the old file and create the new one that inserts some data in the middle. Copy the header, insert the new lines, output all the old line into the new file. I could write to a temp file and move that later, but am I doing anything else stupid?
If you can reproduce this behavior but don't know, leave a comment. Maybe there's something else odd about my system.
my $changes = "Changes";
my $bak = $changes . ".bak";
rename $changes, $bak or die "Could not backup $changes. $!\n";
open my $in, '<', $bak or die "Could not read old $changes file! $!\n";
open my $out, ">", $changes;
# comment this print line and there's no problem
print {$out} 'Hello';
close $out;
close $in;
I know this is an old question, but this might be been related to a bug Apple's filesystem handling had about a year ago. We ran into some problems with the file metadata (mtime?) not getting set correctly in certain situations.
When you run into problems like this with perl, python, node, etc., try doing the same operation in a different language to see if the same behavior obtains. If so, that's likely an OS bug (most of these scripting languages often are thin wrappers around the c libraries anyway).
Cheers.
I'm having trouble monitoring a file for changes. I need to be able to know when a file changes, and when it does, I need the new line that was added. I intend to parse each line and find ones that match certain criteria, and act on information in those lines. I know the expected number of matching lines ahead of time, but I do not know how many lines in total will be added to the file, or where the matching lines will be.
I've tried 2 packages so far, with no avail.
fsnotify/fsnotify
As fas as I can tell, fsnotify can only tell me when a file is modified, not what the details of the modification was. Since I need to know what exactly was added to the file, this is no good for me.
(As a side-question, can this be run in a loop? The example that I tried exited after just one modification. I need to monitor for multiple modifications.)
hpcloud/tail
This package tries to mimic the Unix tail command, but it seems to have its own issues. The output that I get includes timestamps and other data - I just want the added line, nothing else. Also, it seems to think a file has been modified multiple times, even when it's just one edit. Further, the deal breaker here is that it does not output the last line if the line was not followed by a newline character.
Delegating to tail
I came across this answer, which suggests to delegate this work to the tail command itself, but I need this to work cross-platform (specifically, macOS, Linux and Windows). I don't believe that an equivalent command exists on Windows.
How do I go about tackling this?
#user2515526,
Usually changed diff is out of scope of file watchers' functionality, because, you know, you could change an image, and a watcher would need to keep a track several Mb of a diff in memory, and what if we have thousands of files?
However, as bad as it sounds, this may be exactly the way you want to implement this (sure, depends on your app, etc. - could be fine for text files), i.e. - keeping a map of diffs (1 diff per file) since last modification. Cannot say I like it, but sounds like fsnotify has no support for changes/diffs that you need.
Also, regarding your question about running in a loop, maybe you can get some hints here: https://github.com/kataras/iris/blob/8370d76910cdd8de043753ed81ae080eae8dc798/utils/file.go
Its a framework that allows to build a server that watches for TypeScript file changes. So sounds similar to your case/question.
Cheers,
-D
I'm trying to find a simple command in bash that opens the last added file in a directory. I came across this and a few other questions but they were always about the last modified, in contrast with last added. Is there a simple way to do this?
I think this
answers why the thing you need is not possible.
Linux filesystems either just don't record creation time or if they do there is no way to access it through standard command line tools. However, there are ways to access it as described here for example.
For systems that do record the time, such as Mac OS X as mentioned in the other question, you can adapt the code you found by using:
ls -tU | head -n1
I got a partial answer to my problem before, and want to solve this problem fully now. The final line of my /Program Files/GNU/vim/_vimrc is
source /homedir/vimsession_file
The filenames that i edit do not change, only their content changes. But, once in a while, i would create a new session file before i exit vim, using
:mks! /homedir/vimsession_file
Everytime i start gVim, i get a message box listing all the files (which I load into the multiple tabs that i have) with a Line number and Character count listed. More detail of this can be found in my orignal post here.
Currently, i am not using the solution proposed in the link given above. The solution i got there was to replace the final line of /Program Files/GNU/vim/_vimrc with the following line:
autocmd VimEnter * source /homedir/vimsession_file
The reason I stopped using the above solution is because my buffers were all getting wiped out (as described in the original post link). So, i was forced to rebuild my buffers every once in a while, when i would restart gVim.
I did search and read in order to solve this on my own. But the closest solution that i saw was here in stackoverflow. But that solution did not work for me either, despite playing with the shortmess variable as suggested there. How can i stop this annoying message box that pops up with OK button, before the start of gVim ? I want to suppress the message box, because the only info i get from it are the line and character count for each file. (NOTE: I looked into the /homedir/vimsession_file and it is about 3500 lines long. I noticed that the file names occur with badd followed by the edit command. For example, i have line 96 and line 164 as below:
Line 96 : badd +16 \Program\ Files\GNU\vim\_vimrc
........
Line 164: edit \Program\ Files\GNU\vim\_vimrc
This pattern repeats for all the other files that get loaded into multiple windows/tabs.
Wanted to post the answer here because there seem to be very few VIM experts who regularly look at stackoverflow. I didn't have the patience to wait many days expecting an answer. I found the answer to my own question, after reading the help file in vim called "starting.txt" which explains the startup/init process of vim and the different initialization files used. The following steps removed the annoying pop-up message box for me, and also made my VIM process start much faster than before due to simplification.
According to what is suggested in starting.txt help file, I separated my numerous tabs/windows/files into different sessions. I recommend reading through this help file (atleast browsing it), if you are a regular user of VIM.
Previously i was lumping numerous files (from different projects) into one single vim session. This is messy and is not the recommended way to use a VIM session file. Before the creation of different session files (for different projects), i first saved my old vim session file so that i can reuse it, during the creation of different session files. You will understand the process clearly if you look at the help file.
I cleaned up my startup procedure further by setting up a new viminfo file, by adding the "-i" parameter to vim.exe (icon) for starting. This was pointed to a new directory and hence gave a fresh start.
The main init files used by vim are viminfo, vimrc and session file. Each is meant for a different purpose. My problem was caused by source /homedir/vimsession_file as the final line of in my vimrc. So, I removed that line, and instead issue that command manually now, after vim starts up (with an empty window). I can source different vimsession_files, in order to load different files (which belong together). On my machine this command takes about 1 second, to load many tabs/windows/files, which belong to a single project/sub-project.
As pointed in the original post URL given in my question, there maybe another way to resolve this by creating and looking at the vimlog file. But i didn't want to bother with that tedious process. The way i am setup now makes more sense to me, because I have various subprojects which properly belong in different sessions of VIM.