Monday, May 18, 2015

Linux - Using debugfs to Recover Deleted File

debugfs is a very useful tool to debug ext2/ext3/ext4 file system. If your file is deleted, it could be possible to recover it via debugfs if the file's file descriptor is still be opened by some process.

Disclaimer: debugfs is some low level process that could be used to examine and modify the underlying file system. That also means, any mistake may trash your file system.


1. Check whether the file descriptor is still being opened by some process

cat /proc/locks | grep {pid}  -- this will list the locks holds by {pid}

ls -al /proc/{pid}/fd/  -- this will list the file descriptor currently opened by {pid}

Note: You could use ps -ef to display the pid of the desired process.

2. Identify the inode number of the delete file.

The easiest way to know the inode number of a file is

ls -i

Example ls -i

$ ls -i example.txt
6710909 example.txt

The inode number for example.txt is 671909

Another way is to use lsof

Example of lsof

$ ps -ef | grep vi
root     24216 22841  0 10:41 pts/2    00:00:00 vi example.txt

$ lsof -p 24216 
vi      24518 root    4u   REG    8,2    12288 6710944 /tmp/.example.txt.swp

The inode number for /tmp/.example.txt.swp is 6710944

3. Identify the filesystem where the inode is from. 

The easiest way is to use the following command

df -h /your/path


$ df -h /tmp
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              57G   20G   34G  37% /

My /tmp is located at /dev/sda2

Using of debugfs to recover the file from inode

1) To use debugfs, you need to first open the file system

debugfs {your_filesystem}


$ debugfs /dev/sda2
debugfs 1.39 (29-May-2006)

2) Use cat command to view the content of the inode

cat < inode_number >

debugfs:  cat <6710909>
hello world

3. Use dump_inode to dump the inode content to a file

dump_inode  < inode_number > /path/to/file


debugfs:  dump_inode <6710909> /tmp/inode_example.txt

4. Check the content of the inode dump. 

You can use ls and cat command to do this.


$ ls -ali *example*
6710909 -rw-r--r-- 1 root root 18 Dec 16 10:54 example.txt
6710944 -rw-r--r-- 1 root root 18 Dec 16 11:07 inode_example.txt

$ cat inode_example.txt
hello world
$ cat example.txt
hello world

As you can see, both files have the identical content. However, you should note that these 2 files have 2 different inode number.

I am still finding a way to restore the dump inode file to the orginal inode number. That is, restore inode_example.txt back to inode number 6710909. If you have some idea, please feel free to tell me.

Saturday, April 11, 2015

Linux - LD_LIBRARY_PATH has no effect if setuid/setgid flag is turned on for executable

If you ever encounter an error "library not found" when running a executable, and, you are very sure that you had setup LD_LIBRARY_PATH correctly, you may want to check if setuid/setgid flag is turned on for the executable.

If you are not sure what is setuid and setgid flag, below are from Wikipedia setuid Topic

setuid and setgid (short for "set user ID upon execution" and "set group ID upon execution", respectively)[1] are Unix access rights flags that allow users to run an executable with the permissions of the executable's owner or group respectively and to change behaviour in directories. They are often used to allow users on a computer system to run programs with temporarily elevated privileges in order to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.
Now, the reason why executable with setgid/setgid flag turned on does not seem to pick up LD_LIBRARY_PATH environment setting is mentioned in the ld man page Environment section


A colon-separated list of directories in which to search for ELF libraries at execution-time. Similar to the PATH environment variable. Ignored in set-user-ID and set-group-ID programs.

So, this simply means that when setuid/setgid flag is turned on, the ld will ignore whatever value set in user LD_LIBRARY_PATH environment variable and use system default library path.

This is mainly for security reason. When setuid/setgid is used, it provides elevated privilege to run an executable. To prevent invoking user to have any way to alter the process, LD_LIBRARY_PATH is ignored.

Monday, March 23, 2015

Windows 7 - Windows 7 hangs on Classpnp.sys during boot up

If you encounter the following in Windows 7

1. After a Windows update, the machine restarted and hang on the Windows logo
2. Since it hangs at the Windows logo, you restart the machine and tries to boot up via Safe Mode (F8 during start up). But soon, you realize that it hangs when reading Classpnp.sys driver

This may be due to Windows update (mainly AHCI/IDE driver update) causes a break to the compatibility of your current hardware, or even, you have a lose hard disk cable.

To solved this issue, do the following

1. Shutdown your machine and restart.
2. Enter BIOS menu (F12, F2, DEL, etc.. depend on your machine manufacturer)
3. Go to Advanced -> SATA Controller Mode (This also depends on your machine manufacturer. Try to find SATA Controller configuration setting)
4. Change from AHCI to Compatibility
5. Save the configuration and restart the machine.


Thursday, February 5, 2015

Lotus Note - Mail folder modification does not synchronize to server

Under normal expectation, the changes made in your local mail folder (ie, mark as read, move mail to folder, add new folder, etc..) should be synchronized to the server so that additional mail clients (such as another Lotus Note mail client in a remote desktop) should pick up such modification.

If the above is not happening (ie, your remote desktop Inbox filled with unread message while you are very sure that you have read your email from a local machine), you may have a "Send Document To Server" replication setting turned off.

To fix this, do the following

1. Open Local Lotus Note client (the one you mostly use to make modification), access to your Inbox
2. Click on File -> Application -> Properties
3. Click on Replication Settings
4. Make sure "Send document to server" check box is checked

Sunday, December 14, 2014

Lotus Notes - Error: "Time Is Too Far in the Future"

If you encouter this error message - Error: "Time Is Too Far in the Future" - when you run nfixup, ncompact, nupdall, etc... Or, you suddenly realized that your Inbox is not displaying recent email, you are most like hit by "Future Date Issue"

To verify whether you had been hit by "Future Date Issue", you can do the following

1. Go to your Inbox then click Alt+Enter. This will open up a document properties dialog
2. Switch to database properties
3. Click on "I" tab and check on the Activity date. If the modified date is in the future, it means that you had been hit by "Future Data Issue"

When this happen, new document will be hidden in your Inbox because they have a delivery date that is in the future. However, you could still see your incoming email from All Document folder.

To fix this, you will have to create a new replica with the following step

1. In your Mail view, go to File -> Replication -> New Replica...
2. It will prompt up a dialog box. Enter a correct Server and File Path. Then click Ok. (It will be best to backup your current nsf file before creating a new replica)
3. It will take awhile to create the new replica depending on the data need to be copy and synchronized from the server.

After the above steps, you should have a new replica with a correct modification date. You can look at the database properties to verify it.

The above is something that works best for me after trying other methods like running nfixup/nupdall command, create a new view with "Future Date" formula, etc...



Tuesday, November 25, 2014

Teradata - ODBC.ini Entry Explained

Actually, detail of Teradata odbc.ini structure can be found in ODBC Driver for Teradata
User Guide. But, it is a 228 pages document. So, the purpose of this blog entry is to provide essential summarized information about what is required in the odbc.ini for connecting to a Teradata database.

Below describe the required tag for the Teradata specific odbc.ini file

ODBC Options Section

This section mainly define the ODBC Driver installation directory.

InstallDir="filepath" //Required. You should provide the full path for Teradata ODBC Driver installation directory. An example default installation directory is /opt/teradata/client/ODBC_64.

ODBC Data Sources Section

This section define the the Data Source Name (DSN) and its corresponding Teradata ODBC Driver

[ODBC Data Sources]
data-source-name="driver" //Required. Provide the DSN and its driver name. An entry for each data source. The driver file should have either .so or .sl extension

Data Source Specification Section

This section define the data source specification for each data source entry listed in the ODBC Data Source Section. The in this section correspond to the ODBC Data Source Section data-source-name.

Driver="driver-path" //Required.  The full path to the Teradata ODBC Driver shared object file. It should be a .so or .sl file
Description="data-source-desc" //Optional. Provide a description for this data source entry
DBCName="IP-addr-or-alias" // Required. The IP address or FQDN (fully qualified domain name) of the Teradata server. This can be multiple entries
Username="name" //Optional. The username to be used by this data source name entry
Password="password" //Optional. The password for the username defined in Username tag.
DefaultDatabase="database-name" //Optional. The default database for this data source name entry

32-bit odbc.ini File Example


[ODBC Data Sources]

Description=My testing Teradata database

Description=My Default DSN

64-bit odbc.ini File Example


[ODBC Data Sources]

Description=Yet another testing DSN

Description=Yet another default database

1. ODBC Driver for Teradata User Guide 

Saturday, October 11, 2014

ODBC - [08001][unixODBC]Could not connect to the server; Could not connect to remote socket immedaitely [ISQL]ERROR: Could not SQLConnect

If you encounter the following error when you test odbc connection with isql

[08001][unixODBC]Could not connect to the server;
Could not connect to remote socket immedaitely
[ISQL]ERROR: Could not SQLConnect

You may have an error in your odbc.ini file. To be specific, you could be using a wrong "key" name for the server or port in your odbc.ini.

Some background. odbc.ini define DSN information in a key-value pair format and the key is vendor specific. Below is an erratic odbc.ini file entry

Driver = ODBC Driver 11 for SQL Server
Description = Microsoft SQL ODBC Driver
Server = your_mssql_server_host
Port = 1433
Database =
[POSTGRESQL9] Driver = PostgreSQL9 Driver
Description = Postgresql ODBC Driver
Server = your_postgresql_server_host
Port = 5432
Database = your_database

With the above entry, MSSQL2005 DSN will work but POSTGRESQL9 DSN will fail.

unixODBC isql will return the following if you try to query POSTGRESQL9 DSN

[shell]$ isql -v POSTGRESQL9 your_user your_password
[08001][unixODBC]Could not connect to the server;
Could not connect to remote socket immedaitely
[ISQL]ERROR: Could not SQLConnect

The problem is.... PostgreSQL does not understand

Server = your_postgresql_server_host

The correct syntax is

Servername = your_postgresql_server_host

So, to fix the error, the correct odbc.ini entry is

Driver = ODBC Driver 11 for SQL Server
Description = Microsoft SQL ODBC Driver
Server = your_mssql_server_host
Port = 1433
Database =
[POSTGRESQL9] Driver = PostgreSQL9 Driver
Description = Postgresql ODBC Driver
Servername = your_postgresql_server_host
Port = 5432
Database = your_database