I have written a fuse mirror file system using FUSE-JNA, Which mirror local directory.
This Mirror file system allow me to open all types of files correctly with no issue but it does not open all types of office files e.g. .docs , .xls etc. And give me be below error while opening any office file.
Note:
I thought its LibreOffice issue, so I removed it and installed OpenOffice. But get the same issue.
Secondly, the errors only pops up when I try to access an office file from my MirrorFileSystem. Office files opens correctly if accessed normally via ubuntu default file system.
So its some thing wrong with my File system.
Finally, (i don't know whether its related to the question or not but) in my mirror file system when I Right Click on a file>Properties> Permission its shows all the fields disabled, as below
This is my getatt() method:
public int getattr(final String path, final StatWrapper stat)
{
....
if (f.isFile())
{
stat.setMode(NodeType.FILE,true,true,true,true,true,true,true,true,true);
stat.size(f.length());
stat.atime(f.lastModified()/ 1000L);
stat.mtime(0);
stat.nlink(1);
stat.uid(0);
stat.gid(0);
stat.blocks((int) ((f.length() + 511L) / 512L));
return 0;
}
...
}
Please guide me how to fix general input/output error while office files?
Office files are not special. There is some other problem with your filesystem implementation, and you need to do more debugging work to find out precisely what the trigger and the cause is. It's very unlikely that the trigger truly is "the file is an office file", unless you have stuff in your filesystem code that operates differently based on the type of file it's dealing with (in which case you should look there). As a first debugging step, you could compare the sha1sum and stat output of the files from the fuse filesystem and from the root filesystem to see if they match. If they don't, adjust the filesystem code such that they do. You could also enable logging on your filesystem class and check if it's returning an I/O error code anywhere. The error message "general input/output error" makes it sound like that is the case.
As for the reason the permissions fields are disabled, that's because the file is owned by root, and you are not root so you can't change the permissions. The reason the file is owned by root is because you set stat.uid(0); and stat.gid(0); in getattr. UID 0 and GID 0 are for the root user and root group respectively. Fuse-JNA already puts the current UID and GID as default stat attributes in getattr, so if you want to use these then just don't call stat.uid(0); or stat.gid(0);.
Thanks for the answer.
I searched on web, on many websites they showed file locking as the reason e.g. https://forum.openoffice.org/en/forum/viewtopic.php?f=10&t=2020 etc
So in fuse, I implemented file lock function and simply return 0
My problem solved. Now I can open all types of office files.
But I do not know, is it perfect solution
Related
In a lua-script (for Domoticz # Raspberry) I apply the following script-segment to generate an htm-file and to put it in the designated folder.
Line02text till Line30text are variables which are dynamically filled elsewhere in the lua-script.
file = io.open("/home/pi/domoticz/scripts/lua/XXXXX.htm", "w+")
-- Opens a file named XXXXX.htm (stored under the designated sub-folder of Domoticz)
-- in append mode
-- write lines to opened file
file:write("SOF<br>")
file:write(Line02text .. "<br>")
file:write(Line03text .. "<br>")
....
file:write(Line29text .. "<br>")
file:write(Line30text .. "<br>")
file:write("EOF<br>")
file:close() -- closes the open file
All seems OK, because the htm-file appears as planned.
Next steps would be to copy the file to different folder, open in browser, etc..
But Owner of the htm-file is 'root' and Permission is 0640.
For further application Owner should be different, and Permission e.g. 777.
Trying manual change or use of chmod results in report 'Permission denied' by server.
Question:
How to set (as result of the lua-script) different Owner and other Permission for the htm-file?
Lua's target is to be as portable as possible, and ownership/permissions management is very os-specific. There's no embedded functions to handle that.
You'll need to expose some native function that will do what you need with files' permissions. Or use some already existing library for that, like maybe lua-fs: (https://github.com/clementfarabet/lua-fs-0.3)
there is some way from inside the "main.js" electron to save a file out of the asar?
I'm fighting with this command to point the way out of the write-only area but I can not do it.
It would be nice that the path was inside /my-project/resources/ and would work even without the electron-package.
let configFilePath = `${__dirname}/../config.json`
db = new loki(configFilePath)
if(fs.existsSync(configFilePath))
db.loadDatabase()
Attempting to write a file within the application installation directory is a bad idea, often the user will not have the permission to do so. Instead you should write files to the location returned by app.getPath('userData').
I've got some code to install a post-script based virtual printer with a port monitor (for printing to PDF). The code works fine on x86 and x64 platforms from WinXP to Win7, unless the PScript5 set of files isn't in the "root" drivers folder. On a few of my test PCs the files were already there, but on a newer Win7 PC I have the files were not already there.
For example, since I know the above is clear as mud, on Windows XP 32-bit, if these files:
ps5ui.dll
pscript5.dll
pscript.hlp
pscript.ntf
Are located in c:\windows\system32\spool\drivers\w32x86\, then my code works. If they aren't, my code fails. The files are always in c:\windows\system32\spool\drivers\w32x86\3\, and the outcome is the same (apparently Windows doesn't look in the "3" sub-folder).
Do I need to copy them from the 3 sub-folder -- is this what others are doing? Doesn't seem like "good practice" for some reason. According to this on MSDN, I can maybe redistribute the files, but I need to contact Microsoft I guess, and I can't figure out how to do that (links are weird, typical).
This is my (cleaned up) code as it runs on Win7 64-bit (32-bit just uses "Windows NT x86" instead of "Windows x64"):
DRIVER_INFO_3 di;
memset(&di,0,sizeof(di));
di.cVersion = 3;
di.pName = "My PDF Printer";
di.pEnvironment = "Windows x64";
di.pDriverPath = "pscript5.dll";
di.pDataFile = "mypdf.ppd";
di.pConfigFile = "ps5ui.dll";
di.pHelpFile = "pscript.hlp";
di.pDependentFiles = "pscript.ntf\0\0";
di.pMonitorName = NULL;
di.pDefaultDataType = "RAW";
if(!AddPrinterDriverEx(NULL,3,(BYTE*)&di,APD_COPY_ALL_FILES|APD_INSTALL_WARNED_DRIVER))
{
char err[1024];
sprintf(err,"Error adding printer driver: 0x%08X",GetLastError());
Prompt(err);
return;
}
AddPrinterDriverEx fails with error code 2, file not found, if any of the above files are not in the root folder. If I copy the files from the "3" sub-folder and then run the exact code again, it works. I've tried without the APD_COPY_ALL_FILES flag also, same error (2) if files not found, and some other error if they are there (I assume an error code meaning files already exist, shouldn't matter as not related to real issue anyway).
You don't need to contact Microsoft; you can freely redistribute the PScript5 files. However, to use AddPrinterDriverEx you must ensure that all required files are in the \windows\system32\spool\drivers\w32x86 folder, and you shouldn't assume they'll be in the \windows\system32\spool\drivers\w32x86\3 folder to copy from. You should provide a copy of them with your installer and copy them there yourself before calling AddPrinterDriverEx.
Are you sure you can freely redistribute the pscript5 files?
According to this article from Xeros you must ask to Microsoft to redistribute them:
Other manufacturers such as Xerox can obtain redistribution rights
for this file and can then incorporate this DLL with their software
applications and print drivers for Microsoft operating systems.
I am customizing the default build process template in TFS 2010.
i am using "DownloadFiles" build activity and in server path i have given "$/TFS/Libraries/Foo.DLL", when i run the execute definition its throwing error as "Access to the path '\ServerName\SharedFolder\BuildName\TempFolder' is denied.".
But when i give server path as "$/TFS/Libraries" its downloading all the files in Libraries folder into shared TempFolder.
But i need do download only one file. Please help..
Thanks in advance..
Now, DownloadFiles does work for a whole folder only:
ServerPath="$/proj/path" - works great, all is downloaded to LocalPath.
ServerPath="$/proj/path/name.ext" - borked.
I've de-compiled DownloadFiles to see why: First it gets a list of server items, in our case just $/proj/path/name.ext. Then, it calculates the local path like this:
localItemPath = Path.Combine(LocalPath,VersionControlPath.MakeRelative(ServerItem, ServerPath));
In this line, the activity assumes that ServerPath is a path. If it's not, then MakeRelative will not recognize it, and the local path will be LocalPath/$/proj/path/name.ext, as the OP has observed.
Also, if ServerPath is not canonical - for example, $/proj/path/../path2, the same will happen. Solution: use VersionControlPath.GetFullPath(myNonCanonicalPath).
You need to grant the user running the build service with write permissions on the shared folder.
http://msdn.microsoft.com/en-us/library/cc668757.aspx
There are two separate Build activities, DownloadFiles for a folder ServerItem and a DownloadFile for a single file ServerItem.I'd expect it should work with DownloadFile.
I'm using aapt tool to remove some files from different folders of my apk. This works fine.
But when I want to add files to the apk, the aapt tool add command doesn't let me specify the path to where I want the file to be added, therefore I can add files only to the root folder of the apk.
This is strange because I don't think that developers would never want to add files to a subfolder of the apk (res folder for example). Is this possible with aapt or any other method? Cause removing files from any folder works fine, and adding file works only for the root folder of the apk. Can't use it for any other folder.
Thanks
The aapt tool retains the directory structure specified in the add command, if you want to add something to an existing folder in an apk you simply must have a similar folder on your system and must specify each file to add fully listing the directory. Example
$ aapt list test.apk
res/drawable-hdpi/pic1.png
res/drawable-hdpi/pic2.png
AndroidManifest.xml
$ aapt remove test.apk res/drawable-hdpi/pic1.png
$ aapt add test.apk res/drawable-hdpi/pic1.png
The pic1.png that will is added resides in a folder in the current working directory of the terminal res/drawable-hdpi/ , hope this answered your question
There is actually a bug in aapt that will make this randomly impossible. The way it is supposed to work is as the other answer claims: paths are kept, unless you pass -k. Let's see how this is implemented:
The flag that controls whether the path is ignored is mJunkPath:
bool mJunkPath;
This variable is in a class called Bundle, and is controlled by two accessors:
bool getJunkPath(void) const { return mJunkPath; }
void setJunkPath(bool val) { mJunkPath = val; }
If the user specified -k at the command line, it is set to true:
case 'k':
bundle.setJunkPath(true);
break;
And, when the data is being added to the file, it is checked:
if (bundle->getJunkPath()) {
String8 storageName = String8(fileName).getPathLeaf();
printf(" '%s' as '%s'...\n", fileName, storageName.string());
result = zip->add(fileName, storageName.string(),
bundle->getCompressionMethod(), NULL);
} else {
printf(" '%s'...\n", fileName);
result = zip->add(fileName, bundle->getCompressionMethod(), NULL);
}
Unfortunately, the one instance of Bundle used by the application is allocated in main on the stack, and there is no initialization of mJunkPath in the constructor, so the value of the variable is random; without a way to explicitly set it to false, on my system I (seemingly deterministically) am unable to add files at specified paths.
However, you can also just use zip, as an APK is simply a Zip file, and the zip tool works fine.
(For the record, I have not submitted the trivial fix for this as a patch to Android yet, if someone else wants to the world would likely be a better place. My experience with the Android code submission process was having to put up with an incredibly complex submission mechanism that in the end took six months for someone to get back to me, in some cases with minor modifications that could have just been made on their end were their submission process not so horribly complex. Given that there is a really easy workaround to this problem, I do not consider it important enough to bother with all of that again.)