Does the "Deepness of the location of a file" matter when using Flidas?
- Inicie sesión o regístrese para enviar comentarios
I have a problem with Flidas I don't know how to explain without using what I call the "deepness of the location of a file".
Do you understand me when I use that expression to make my question?
For example, I would say that initrd.img is not deeply located in the file structure because its location is /
I would also say that it is located in the first level of deepness.
On the other hand, I would say that dao.h 's location is quite deep, because its location is /usr/include/libspreadsheet-1.12/spreadsheet/tools/
I would also say that it is located in the 6th level of deepness.
I am a translator!
you gotta go deep
I discovered the problem when trying to link an .HTML document that is at the 16th level of deepness to another .HTML document that is also at the same level of deepness but of another folder.
I have linked other .HTML documents before without problems.
I currently don't recall the deepness at which they were located.
I am a translator!
16th level of deepness
Are you saying the path is too long and you are getting an error?
Thank you for asking
I'm getting an error and I don't know if long paths are compatible with Flidas.
This is what I would like to know:
Does Flidas have some limit regarding the length of the paths that are used with it?
> I'm getting an error
Please copy/paste or screenshot the error.
Hello chaosmonk
Though I want to thank all who have tried to help me with this problem, I'm specially addressing you because when reading this topic before sending this message I discovered that despite the information I provided in my messages from Thu, 11/10/2018 - 00:39 UTC+1 and from Thu, 11/10/2018 - 06:18 UTC+1 were in response to your very useful request from Wed, 10/10/2018 - 22:45 UTC+1 I directed (by mistake) that information to another user who was also trying to help me at that time. Sorry for the delay in letting you know these things just now.
The problem has been solved but it took a lot of time and tests that unfortunately have only left suspicions and not certainties.
I can't say I know what has happened because making some of the suggested changes (and others) in the starting link did not solve the problem and my suspicions on a typo have again increased because at the level of the destination file's name, I found a sort of typo that is not easy to discover if you use the "Caja File Manager 1.12.7" in the "Browser" mode and "icon view".
After correcting it the problem has practically disappeared.
I'm using "practically disappeared" because the first time I clicked on the starting link after having corrected the up-mentioned typo, I got a response that was similar to the one I attached to my post on Thu, 10/11/2018 - 06:18 UTC+1.
But since that last failure which happened several days ago, the troublesome link has never failed again.
I reiterate: Thanks to all who tried to help!!
this table says it doesnt have a path limit:
https://en.wikipedia.org/wiki/Comparison_of_file_systems
the filename limit is 255 bytes, but that doesnt apply here.
https://en.wikipedia.org/wiki/Comparison_of_file_systems#cite_note-note-12-11 actually says:
Linux has a pathname limit of 4,096.
good to know.
a lot longer than would apply, but i actually found it difficult to believe that no client or program had a limit. one of the goals of the gnu project is to remove such arbitrary limits when possible.
i believe cpu architecture gives a limit too-- but greater than 4,096.
@ loldier
Thank you for trying to help.
I have made so many attempts to solve the problem and changes in the address of the starting link that currently when I click on it I'm not receiving an error screen and I am able to access folders that have a much longer path than the one with which the problem began.
For example if the starting link was:
<a>href="file:///media/trisquel/STORE%20N%20GO/YA16G5708003700ATL/IT/GENERAL/SOFTWARE/UNIX/LINUX/TRISQUEL/DOWNLOAD/FLIDAS/BURN/IRC/PIDGIN/LOGS_OF_CHATS/#TRISQUEL/2018-10-10_16h53.html"> this is the current starting link </a>
my Abrowser would ask me to check the path's spelling and the content of the last folder and to try again.
The error only disappeared with a shorter starting link like this:
<a>href="file:///media/trisquel/STORE%20N%20GO/YA16G5708003700ATL/IT/GENERAL/SOFTWARE/UNIX/LINUX/TRISQUEL/DOWNLOAD/FLIDAS/"> this is a shorter starting link </a>
Now, with the current starting link, though Abrowser shows me what can be seen in the attachment; that is not what I'm expecting. I'm looking forward to see the contents of 2018-10-10_16h53.html. But I don't know if that is possible and (if it is) how to achieve it.
There is something else that has changed since my first post: I'm not so sure that this is a problem related to a long path.
I'm eager to know about your point of view.
Thanks in advance.
There exists a maximal number of characters in the URL: https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers
However, your long URL should not even be close to reaching the limit. Probably a typo...
@ Magic Banana
Thank you for the link!
I also distrust my keyboard skills and therefore I haven't ruled typos out.
But I also suspect of the shallowness of my knowledge on links and on the way in which I configured the storage media I am using.
I am trying to gather evidence about these factors and eventually submit them here in the forum for consideration.
And thank you very much for your thoughts!
@ loldier
This is the sort of reply I received from Abrowser when the problem began
try going to
f i l e : / / /
without the spaces, and then clicking on media, then the next folder, until you get to the file you wanted to open.
that will save you the hassle of typos. you can probably drag the file onto the url bar (or browser window) as well.
you can probably drag the file to the bookmarks bar and then click on the bookmarks. good luck.
You have blanks in the names. Put 'store n go' in quotes and you should be ok. Or the whole pathname.
I have posted a message thanking you all and apologizing to chaosmonk.
- Inicie sesión o regístrese para enviar comentarios